From ram-bounces@iab.org Thu Mar 01 02:04: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 1HMfHJ-00006X-J5; Thu, 01 Mar 2007 02:00:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMfHH-00006S-M3 for ram@iab.org; Thu, 01 Mar 2007 02:00:35 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMfHG-0000gO-4b for ram@iab.org; Thu, 01 Mar 2007 02:00:35 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 630A0212D4B for ; Thu, 1 Mar 2007 09:00:20 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 291DF212D48 for ; Thu, 1 Mar 2007 09:00:20 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B6CD3B7-0B90-4E9F-AEC0-55E417865F2E@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Thu, 1 Mar 2007 09:00:17 +0200 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Subject: [RAM] PASH: Another SHIM6 proxying draft, in addition to pshim6 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 Another new draft, http://www.ietf.org/internet-drafts/draft-nikander- ram-pash-00.txt , outlines how to proxy SHIM6 in a slightly different way than PSHIM6; it also discusses HIP proxying. It is not as detailed as PSHIM6; instead it tries to show that it is indeed possible to use SHIM6 (and HIP) in a LISP-like way. However, it is important to remember that SHIM6 and especially HIP provide much more than LISP does; see e.g. Markus Stenberg's recent message. From a deployment point of view the biggest difference between PSHIM6 and PASH seems to be that PASH outlines scenarios that require less machinery between the legacy hosts and the network than PSHIM6 does; PSHIM6 also includes some discussion about that in Section 7. The generix draft [1] tries to generalise the different approaches, but unfortunately as of today it may be still too scanty to be really comprehensible, at least if the reader is not willing to think hard. However, I hope that the PASH (and PSHIM6) help to digest the generix message. The more architectural message here is that there indeed seems to be pretty independent dimensions of where to implement id/loc split: where to implement it vertically (in the stack), and where to implement it horizontally (in the host/network). A third (though not independent) dimension is the nature and routability/resolvability of identifiers, along the lines of LISP 1, 1.5, 2, and 3 deployment scenarios. --Pekka Nikander [1] http://www.ietf.org/internet-drafts/draft-nikander-ram-generix- proxying-00.txt On 28 Feb 2007, at 13:45, marcelo bagnulo braun wrote: > Hi, > > i have included in this draft some level of detail on how to do > proxies in shim6, in order to support unmodified hosts, allow some > middle boxes to perform egress path selection and provide PI > identifiers, so that we can have an idea of how this would look > like in the shim approach > > Comments are welcome > > Regards, marcelo > > Inicio mensaje reenviado: > >> De: Internet-Drafts@ietf.org >> Fecha: 27 de febrero de 2007 21:50:02 GMT+01:00 >> Para: i-d-announce@ietf.org >> Cc: Asunto: I-D ACTION:draft-bagnulo-pshim6-00.txt >> Responder a: internet-drafts@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Proxy Shim6 (P-Shim6) >> Author(s) : M. Bagnulo >> Filename : draft-bagnulo-pshim6-00.txt >> Pages : 22 >> Date : 2007-2-27 >> >> This draft discusses extensions to the shim6 architecture to >> support >> shim6 proxies that would allow the provision of the following >> capabilities: >> o Provide Upper Layer Identifier portability. >> o Provide Traffic Engineering policy enforcement. >> o Off-load of the shim6 context management from the actual >> peers of >> the communication. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-bagnulo-pshim6-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the >> body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-bagnulo-pshim6-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-bagnulo-pshim6-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2007-2-27120849.I-D@ietf.org> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce > > > _______________________________________________ > 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 Thu Mar 01 06: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 1HMj6E-0004KU-6C; Thu, 01 Mar 2007 06:05:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMj6C-0004K9-Tm for ram@ietf.org; Thu, 01 Mar 2007 06:05:24 -0500 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 1HMj6A-0006nK-Po for ram@ietf.org; Thu, 01 Mar 2007 06:05:24 -0500 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 l21B2n6Q023580; Thu, 1 Mar 2007 13:03:15 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 13:04:53 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 13:04:52 +0200 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] Can we forget LISP, please? Date: Thu, 1 Mar 2007 13:04:50 +0200 Message-ID: In-Reply-To: <0E99446F-F09C-474A-B403-EA95616A4995@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Can we forget LISP, please? Thread-Index: Acdbg/WAa5QqBSEiSuOTtaklwShbVgAbRbBA References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <60C4A248E730F249990993E3B9BD44D80322B119@xmb-sjc-218.amer.cisco.com> <0E99446F-F09C-474A-B403-EA95616A4995@muada.com> From: To: X-OriginalArrivalTime: 01 Mar 2007 11:04:52.0871 (UTC) FILETIME=[70104970:01C75BF1] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070301130315-5308FBB0-09E78C99/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ram@ietf.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 wrote: > wrote: > >> i.e. the use of >> cryptographically bound identities as IDs? It seems to me that LISP=20 >> would work rather well with CGAs as in SHIM6? > >But wouldn't that require changes to hosts? And if you accept=20 >that, why not simply adopt shim6 itself, with or without some=20 >modifications? (It's not like it's finished just yet.) > I think Pekka and Kristian nailed this down pretty well in the PASH draft earlier today :-) >> 2. Current practice allows only for ~64 crypto-bits in a=20 >CGA. It would=20 >> be better to carve out a portion of the IPv6 address space for e.g.=20 >> /28 prefixes (for EID resolution aggregation) and ~100 bits for=20 >> crypto. >> Would be more secure and future proof. > >Like HIP, you mean? :-) > This aspect also discussed in the PASH draft, it seems. Regards, Jarno _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 01 06:08: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 1HMj8l-0005Bm-Ob; Thu, 01 Mar 2007 06:08:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMj8k-0005Ai-QG for ram@ietf.org; Thu, 01 Mar 2007 06:08:02 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMj8j-00075k-Hu for ram@ietf.org; Thu, 01 Mar 2007 06:08:02 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Mar 2007 12:08:01 +0100 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 l21B80Rl026863; Thu, 1 Mar 2007 12:08:00 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp85.cisco.com [10.61.64.85]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l21B7wC8002225; Thu, 1 Mar 2007 12:07:58 +0100 (MET) Message-ID: <45E6B40D.3000401@cisco.com> Date: Thu, 01 Mar 2007 12:07:57 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: "John G. Scudder" Subject: Re: [RAM] Can we forget LISP, please? References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com> <5BE0C06B-0A5F-4057-92EC-D90582B08FB8@bgp.nu> In-Reply-To: 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=262; t=1172747281; x=1173611281; 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]=20Can=20we=20forget=20LISP,=20please? |Sender:=20; bh=Y4g8uXArh+A6c2EYBQniayYSvoXs5kjg8GQJAjTwgcA=; b=TFfTX6sLooMGspJHPs7Y+ZjWLhOtcpU6HHhOYEEOOcImmze2d6r+S8ivZCbL/VWLT9SiYo0E fITYxhjvN3mo/7u4+dHgXXxErokuUOYAZPCvMRJfFt1I/9eUIiFd1++9; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ram@ietf.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 Oh please. >> >>> Hmm. The BGP RIB is a sort of a cache. >> >> Huh? How do you figure? > > Let me rephrase that: No, it's not. A cache is merely a temporary store. So how about responding to the meat of Dino's proposal rather than being pedantic? _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 01 10:29: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 1HMnC4-0002Yb-Vr; Thu, 01 Mar 2007 10:27:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnC2-0002Sw-N4 for ram@ietf.org; Thu, 01 Mar 2007 10:27:42 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMnC0-00049H-7f for ram@ietf.org; Thu, 01 Mar 2007 10:27:42 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id l21FRXif041419; Thu, 1 Mar 2007 07:27:33 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.23.1.141]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l21FRVB00393; Thu, 1 Mar 2007 07:27:31 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070301101217.0354d080@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 01 Mar 2007 10:27:26 -0500 To: Eliot Lear , "John G. Scudder" From: Ross Callon Subject: Re: [RAM] Can we forget LISP, please? In-Reply-To: <45E6B40D.3000401@cisco.com> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com> <5BE0C06B-0A5F-4057-92EC-D90582B08FB8@bgp.nu> Mime-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ram@ietf.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="===============1779983148==" Errors-To: ram-bounces@iab.org --===============1779983148== Content-Type: multipart/alternative; boundary="=====================_1634870==_.ALT" --=====================_1634870==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:07 PM 3/1/2007 +0100, Eliot Lear wrote: >Oh please. >>> >>>>Hmm. The BGP RIB is a sort of a cache. >>> >>>Huh? How do you figure? >> >>Let me rephrase that: No, it's not. > >A cache is merely a temporary store. So how about responding to the meat >of Dino's proposal rather than being pedantic? My understanding of a cache is that it is a temporary store of **PART** of the database, and not all of the database. My interpretation of John's comment is that he is concerned about the partial nature of the cache, and not the temporary nature of the cache. From Wikipedia: "Caches have proven to be extremely effective in many areas of computing because access patterns in typical computer applications have locality of reference." Others may be able to comment better than I on the experience with cache based routers. My impression is that these are okay very close to the edge of small networks, but have experienced significant problems in core service providers. Ross --=====================_1634870==_.ALT Content-Type: text/html; charset="us-ascii" At 12:07 PM 3/1/2007 +0100, Eliot Lear wrote:
Oh please.

Hmm. The BGP RIB is a sort of a cache.

Huh?  How do you figure?

Let me rephrase that:  No, it's not.

A cache is merely a temporary store.  So how about responding to the meat of Dino's proposal rather than being pedantic?

My understanding of a cache is that it is a temporary store
of **PART** of the database, and not all of the database. My
interpretation of John's comment is that he is concerned about
the partial nature of the cache, and not the temporary nature of
the cache.

From Wikipedia:
    "Caches have proven to be extremely effective in many areas
    of computing because access patterns in typical computer
    applications have locality of reference."

Others may be able to comment better than I on the experience
with cache based routers. My impression is that these are okay
very close to the edge of small networks, but have experienced
significant problems in core service providers.

Ross --=====================_1634870==_.ALT-- --===============1779983148== 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 --===============1779983148==-- From ram-bounces@iab.org Thu Mar 01 11:02:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnjK-0003wF-IM; Thu, 01 Mar 2007 11:02:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnjJ-0003w3-DD for ram@ietf.org; Thu, 01 Mar 2007 11:02:05 -0500 Received: from alnrmhc15.comcast.net ([204.127.225.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMnjH-0002jN-5Z for ram@ietf.org; Thu, 01 Mar 2007 11:02:05 -0500 Received: from [192.168.2.2] (c-66-30-121-250.hsd1.ma.comcast.net[66.30.121.250]) by comcast.net (alnrmhc15) with SMTP id <20070301160125b1500scqjte>; Thu, 1 Mar 2007 16:01:56 +0000 In-Reply-To: <9021D990-01EE-48DC-AEA6-7DD2DEF34ECA@cisco.com> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com> <82C79563-790E-4E8C-8EE8-074429B42B5E@muada.com> <9021D990-01EE-48DC-AEA6-7DD2DEF34ECA@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <43F926FF-75BC-42DB-B49C-DED18AE02283@lilacglade.org> Content-Transfer-Encoding: 7bit From: Margaret Wasserman Subject: Re: [RAM] Can we forget LISP, please? Date: Thu, 1 Mar 2007 11:01:23 -0500 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ram@ietf.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 Feb 28, 2007, at 8:47 PM, Dino Farinacci wrote: >> You can of course always find more address bits by adding extra >> tunnel headers, which also helps with keeping the whole thing more >> backward compatible. This could actually work, but then we're back >> at how to find outer tunnel addresses (LOCs) to go along with >> inner tunnel addresses (IDs). > > Yep. Exactly. Regardless of whether we use an IP-in-IP tunnel approach, or an IP-in- LISP approach, or any other tiered routing approach, we have the same mapping problem. Given a non-local, non-globally-routable end-point identifier, how do we find a globally routable locator so that we can get our packets there? Without a mapping mechanism that meets application requirements and scales better than current IP routing, we're just moving the problem around. Margaret _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 01 11:04: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 1HMnla-00074m-7D; Thu, 01 Mar 2007 11:04:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnge-0001yE-1q for ram@ietf.org; Thu, 01 Mar 2007 10:59:20 -0500 Received: from [64.25.87.235] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMngZ-0002Gn-IL for ram@ietf.org; Thu, 01 Mar 2007 10:59:20 -0500 Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1912021; Thu, 01 Mar 2007 10:59:14 -0500 In-Reply-To: <9021D990-01EE-48DC-AEA6-7DD2DEF34ECA@cisco.com> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com> <82C79563-790E-4E8C-8EE8-074429B42B5E@muada.com> <9021D990-01EE-48DC-AEA6-7DD2DEF34ECA@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: Margaret Wasserman Subject: Re: [RAM] Can we forget LISP, please? Date: Thu, 1 Mar 2007 10:59:12 -0500 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Thu, 01 Mar 2007 11:04:25 -0500 Cc: ram@ietf.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 Feb 28, 2007, at 8:47 PM, Dino Farinacci wrote: >> You can of course always find more address bits by adding extra >> tunnel headers, which also helps with keeping the whole thing more >> backward compatible. This could actually work, but then we're back >> at how to find outer tunnel addresses (LOCs) to go along with >> inner tunnel addresses (IDs). > > Yep. Exactly. Regardless of whether we use an IP-in-IP tunnel approach, or an IP-in- LISP approach, or any other tiered routing approach, we have the same mapping problem. Given a non-local, non-globally-routable end-point identifier, how do we find a globally routable locator so that we can get our packets there? Without a mapping mechanism that meets application requirements and scales better than current IP routing, we're just moving the problem around. Margaret _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 01 11:19: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 1HMnz5-0001o2-K0; Thu, 01 Mar 2007 11:18:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMnz3-0001lz-Kn for ram@iab.org; Thu, 01 Mar 2007 11:18:21 -0500 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 1HMnyy-00055n-Mw for ram@iab.org; Thu, 01 Mar 2007 11:18:21 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l21GI2dp010351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Mar 2007 08:18:02 -0800 (PST) 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 l21GI20u014112; Thu, 1 Mar 2007 10:18:02 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l21GHrsV013803; Thu, 1 Mar 2007 10:18:01 -0600 (CST) 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); Thu, 1 Mar 2007 08:18:00 -0800 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] Architectural comments on draft-farinacci-lisp-00 Date: Thu, 1 Mar 2007 08:17:59 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040490E7@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <20070227004027.F0272872FF@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Architectural comments on draft-farinacci-lisp-00 Thread-Index: AcdaB+HV5vkD/YKITQe3SdVrVMe1DABscssg From: "Henderson, Thomas R" To: "Noel Chiappa" , X-OriginalArrivalTime: 01 Mar 2007 16:18:00.0224 (UTC) FILETIME=[2E32DA00:01C75C1D] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 =20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Monday, February 26, 2007 4:40 PM > To: ram@iab.org > Cc: jnc@mercury.lcs.mit.edu > Subject: RE: [RAM] Architectural comments on draft-farinacci-lisp-00 >=20 >=20 > So here's my question: if I have a "locator" which globally, uniquely > identifies something, but which includes topological location=20 > information > in the name for only a limited scope, what happens in the=20 > limiting case, > where that scope is reduced to the the named entity itself?=20 > In what sense > is that "locator" a locator any more? >=20 This is an interesting line of thinking I'd like to push further w.r.t. LISP. What if one did not stop at the first hop router with LISP but instead pushed it all the way into the host? In such a scenario, what aspects of LISP would be objectionable for whatever reason (locator binding security, properties of the resolution system, perhaps)? If such design points are objectionable in the host context, what is different then when implementing them instead in the tunnel routers? Should LISP worry about these objections? Or maybe the question is should LISP worry about them now as opposed to later? This question may be restating Pekka's observation in the ILSE draft that, aside from deployment concerns, where or how the split is implemented is perhaps not as important as other properties that people have been concerned about regarding the ID/locator split. Maybe some will answer that there are no such objectionable design points for host-based LISP and we are already doing something very similar (mobile IP). Is LISP essentially a site-multihoming variant of NEMO with a different control/resolution plane? Tom _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 01 13:41:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMqBQ-0006yL-M3; Thu, 01 Mar 2007 13:39:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMqBP-0006xU-Gl for ram@iab.org; Thu, 01 Mar 2007 13:39:15 -0500 Received: from [207.179.9.76] (helo=smtp1.extremenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMqBO-00071X-8F for ram@iab.org; Thu, 01 Mar 2007 13:39:15 -0500 Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id E62C27946 for ; Thu, 1 Mar 2007 10:39:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Thu, 1 Mar 2007 13:39:03 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [RAM] Terminology: ID/Locator split 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 In some off-list conversations, it seems that there are varying definitions for the phrase "ID-Locator split". I suspect the variance in definitions for that phrase is causing some confusion in discussions on this list. To my mind, when one talks about an "ID/Locator split", an essential property is that one has both: 1) a "Locator" which is ONLY used for packet forwarding and is NEVER visible above the network-layer (e.g. no name ever used for network-layer packet forwarding is ever visible to TCP) && 2) an "Identifier" that is used by the transport-layer (e.g. in TCP session state, such as TCP pseudo-header checksum), might be used above the transport-layer, and is NEVER used for network-layer packet forwarding. If other folks have CRISP and CLEAR alternative definitions for "ID-Locator split", then it might be interesting to know precisely what those alternative definitions are... Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 01 13:51: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 1HMqMd-000613-Dj; Thu, 01 Mar 2007 13:50:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMqMc-00060t-HA for ram@iab.org; Thu, 01 Mar 2007 13:50:50 -0500 Received: from [207.179.9.76] (helo=smtp1.extremenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMqMb-0000JE-9B for ram@iab.org; Thu, 01 Mar 2007 13:50:50 -0500 Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 4F56E7946 for ; Thu, 1 Mar 2007 10:50:44 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <0DEDCA45-B2F5-4D0D-BDD8-DE854D23CFA9@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Thu, 1 Mar 2007 13:50:42 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [RAM] Re: LISP 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 Earlier, Dino said: % But for one thing, we are listening to the operators, % because [if] they say no way off the bat, then the proposal % isn't going anywhere. The above is both true and quite reasonable for the LISP proposal, primarily because it is a router-centric proposal and the network operators control most of the deployed routers. I do not think it is true that network operators can (or would :-) unilaterally be able to stop some other form of scaling solution that involved only host changes. Purely as a hypothetical example, if some alternative scalable multi-homing approach existed that only involved host stack changes, then the network operators neither would nor could stop that. Other factors (e.g. practical issues with incremental upgrading of host networking code, practical issues with incremental deployment) might well impede a host-centric solution, of course. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 01 14:31: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 1HMqyZ-0004dz-W5; Thu, 01 Mar 2007 14:30:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMqyX-0004ds-WF for ram@iab.org; Thu, 01 Mar 2007 14:30:02 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMqyV-0006iK-65 for ram@iab.org; Thu, 01 Mar 2007 14:30:01 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 01 Mar 2007 14:29:55 -0500 X-IronPort-AV: i="4.14,238,1170651600"; d="scan'208"; a="53857600:sNHT43707920" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l21JTsdX004867; Thu, 1 Mar 2007 14:29:54 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l21JTGVp020558; Thu, 1 Mar 2007 14:29:46 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 14:29:41 -0500 Received: from [10.86.240.184] ([10.86.240.184]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 14:29:40 -0500 Message-ID: <45E729B0.80303@employees.org> Date: Thu, 01 Mar 2007 14:29:52 -0500 From: Scott W Brim Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] Terminology: ID/Locator split References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> In-Reply-To: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2007 19:29:40.0794 (UTC) FILETIME=[F51291A0:01C75C37] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral 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 On 03/01/2007 13:39 PM, RJ Atkinson wrote: > 1) a "Locator" which is ONLY used for packet forwarding > and is NEVER visible above the network-layer > (e.g. no name ever used for network-layer packet forwarding > is ever visible to TCP) > && > > 2) an "Identifier" that is used by the transport-layer > (e.g. in TCP session state, such as TCP pseudo-header checksum), > might be used above the transport-layer, and > is NEVER used for network-layer packet forwarding. I don't get to stop by this party very often, but have you agreed that there a requirement that there be a single "identifier" down in the transport layer? The last line of (2) is certainly true. I'm wondering about the 2nd line. Scott _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 01 14:35: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 1HMr3M-0008Gz-7a; Thu, 01 Mar 2007 14:35:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMr3L-0008Gu-Bj for ram@iab.org; Thu, 01 Mar 2007 14:34:59 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMr3J-0007ce-VU for ram@iab.org; Thu, 01 Mar 2007 14:34:59 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 01 Mar 2007 11:34:56 -0800 X-IronPort-AV: i="4.14,238,1170662400"; d="scan'208"; a="44215075:sNHT360685026" 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 l21JYuoJ014763; Thu, 1 Mar 2007 11:34:56 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l21JYhDu026990; Thu, 1 Mar 2007 11:34:50 -0800 (PST) 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, 1 Mar 2007 11:34:43 -0800 Received: from [192.168.0.4] ([10.21.81.104]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 11:34:43 -0800 In-Reply-To: <0DEDCA45-B2F5-4D0D-BDD8-DE854D23CFA9@extremenetworks.com> References: <0DEDCA45-B2F5-4D0D-BDD8-DE854D23CFA9@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <12D4BF21-EC2C-43A2-9AD8-D583B33CC7B1@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Re: LISP Date: Thu, 1 Mar 2007 11:34:46 -0800 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Mar 2007 19:34:43.0620 (UTC) FILETIME=[A9922640:01C75C38] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=607; t=1172777696; x=1173641696; 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]=20Re=3A=20LISP |Sender:=20; bh=ocMrvwaY1h36uHZ0m/i1q4yiGasoGofh59oYxUKOikU=; b=GLPUHyi3eo9lZXCr8kMzxoP+mkz5N4aY5KmisAnYNb5e1cnhfc7S/vAW/1VMdjZkkjGpVQjq r1RVNUlMf1A0Vcj5HJay+os76Vwf1PiqAispULCyFIhGI6f2S7VPLAp8; 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 > Purely as a hypothetical example, if some alternative > scalable multi-homing approach existed that only involved > host stack changes, then the network operators neither > would nor could stop that. Other factors (e.g. practical > issues with incremental upgrading of host networking code, > practical issues with incremental deployment) might well > impede a host-centric solution, of course. Agree. My reference to "operators" also includes IT operators in an enterprise managing their multi-homed site. In this case, they have to manage hosts as well as switches and routers. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 01 15:08:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMrXq-0000MV-Ps; Thu, 01 Mar 2007 15:06:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMrXp-0000MI-7r for ram@iab.org; Thu, 01 Mar 2007 15:06:29 -0500 Received: from [207.179.9.76] (helo=smtp1.extremenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMrXn-00035a-VB for ram@iab.org; Thu, 01 Mar 2007 15:06:29 -0500 Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 7ABAA7946; Thu, 1 Mar 2007 12:06:18 -0800 (PST) In-Reply-To: <12D4BF21-EC2C-43A2-9AD8-D583B33CC7B1@cisco.com> References: <0DEDCA45-B2F5-4D0D-BDD8-DE854D23CFA9@extremenetworks.com> <12D4BF21-EC2C-43A2-9AD8-D583B33CC7B1@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51862202-8943-43F4-B8E5-F674BF6411CB@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Re: LISP Date: Thu, 1 Mar 2007 15:06:16 -0500 To: Dino Farinacci X-Mailer: Apple Mail (2.752.2) 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 On 1 Mar 2007, at 14:34, Dino Farinacci wrote: >> Purely as a hypothetical example, if some alternative >> scalable multi-homing approach existed that only involved >> host stack changes, then the network operators neither >> would nor could stop that. Other factors (e.g. practical >> issues with incremental upgrading of host networking code, >> practical issues with incremental deployment) might well >> impede a host-centric solution, of course. > > Agree. My reference to "operators" also includes IT operators in an > enterprise managing their multi-homed site. In this case, > they have to manage hosts as well as switches and routers. "IT operators" might well NOT be managing the hosts, whether or not they desire to do so, think they are doing so, etc. I know of many organisations where IT says/claims that it manages end systems, but in practical terms does not actually manage the end user laptops, to give one example. Such IT folks might or might not even realise when they aren't managing the end system. For example, consider a host that IT thinks it controls because IT (erroneously) thinks the system is running Windows, but actually the user has booted the machine [without IT knowledge that dual-booting is even enabled on that system] into BSD or Linux, rather than Windows. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 01 17:20:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMtbJ-0005JG-C2; Thu, 01 Mar 2007 17:18:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMtbI-0005IY-Bw for ram@ietf.org; Thu, 01 Mar 2007 17:18:12 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMtbF-0000Iw-Nj for ram@ietf.org; Thu, 01 Mar 2007 17:18:12 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2007 14:18:10 -0800 X-IronPort-AV: i="4.14,238,1170662400"; d="scan'208,217"; a="395589522:sNHT73684276" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l21MI91k000788; Thu, 1 Mar 2007 14:18:09 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l21MI0iC012739; Thu, 1 Mar 2007 14:18:04 -0800 (PST) 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); Thu, 1 Mar 2007 14:18:03 -0800 Received: from [171.71.55.245] ([171.71.55.245]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 14:18:03 -0800 In-Reply-To: <5.0.0.25.2.20070301101217.0354d080@zircon.juniper.net> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com> <5BE0C06B-0A5F-4057-92EC-D90582B08FB8@bgp.nu> <5.0.0.25.2.20070301101217.0354d080@zircon.juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <36A5EE73-4269-4BF6-BB9B-06EEBB4F06F5@cisco.com> From: Tony Li Subject: Re: [RAM] Can we forget LISP, please? Date: Thu, 1 Mar 2007 14:18:01 -0800 To: Ross Callon X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Mar 2007 22:18:03.0450 (UTC) FILETIME=[7AB989A0:01C75C4F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2342; t=1172787489; x=1173651489; c=relaxed/simple; s=sjdkim8002; 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]=20Can=20we=20forget=20LISP,=20please? |Sender:=20; bh=nvBVrmVzq/hBWFVr3lsdZkfMxQuiE5u7jpFCpO5R6l4=; b=l2gV3rZQ4Ok2F6iZFsg6VuY4Duhy+Cr3ntz/jRf8A2BrXBEQDau5wKPTa8nw1ruz8Yeb3X/2 /mBOeq85D/dH7aFWO1ju0obGkLTRUcYmiYOm1XKgCz8M5s+G1PeTzMnB; Authentication-Results: sj-dkim-8; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ram@ietf.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="===============1357084279==" Errors-To: ram-bounces@iab.org --===============1357084279== Content-Type: multipart/alternative; boundary=Apple-Mail-12--940730040 --Apple-Mail-12--940730040 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 1, 2007, at 7:27 AM, Ross Callon wrote: > Others may be able to comment better than I on the experience > with cache based routers. My impression is that these are okay > very close to the edge of small networks, but have experienced > significant problems in core service providers. I'll vouch for this, if folks are still doubtful. In one experiment that we did, the "working set" for the forwarding cache worked out to be 85% of the RIB. At that point, why bother? Tony --Apple-Mail-12--940730040 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Mar 1, 2007, at = 7:27 AM, Ross Callon wrote:

Others may be able = to comment better than I on the experience=A0
with cache based routers. = My impression is that these are okay
very close to the edge of small = networks, but have experienced=A0
significant problems in = core service providers.=A0


I'll vouch for = this, if folks are still doubtful.=A0 In one experiment that we did, the = "working set" for the forwarding cache worked out to be 85% of the RIB.=A0= At that point, why bother?

Tony

= --Apple-Mail-12--940730040-- --===============1357084279== 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 --===============1357084279==-- From ram-bounces@iab.org Thu Mar 01 20:08: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 1HMwEA-0007OP-Am; Thu, 01 Mar 2007 20:06:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMwE9-0007M7-0B for ram@ietf.org; Thu, 01 Mar 2007 20:06:29 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMwE7-0005Fj-MZ for ram@ietf.org; Thu, 01 Mar 2007 20:06:28 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Mar 2007 17:06:27 -0800 X-IronPort-AV: i="4.14,239,1170662400"; d="scan'208"; a="117257427:sNHT43264548" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2216QYS001780; Thu, 1 Mar 2007 17:06:26 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2216GGk001415; Thu, 1 Mar 2007 17:06:16 -0800 (PST) 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); Thu, 1 Mar 2007 17:06:14 -0800 Received: from [10.253.236.43] ([10.21.81.188]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 17:06:14 -0800 In-Reply-To: References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <60C4A248E730F249990993E3B9BD44D80322B119@xmb-sjc-218.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6B864A95-1728-4761-8A58-5ACD3F0BE7DB@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Can we forget LISP, please? Date: Thu, 1 Mar 2007 17:06:16 -0800 To: "" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Mar 2007 01:06:14.0358 (UTC) FILETIME=[F95FE760:01C75C66] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=680; t=1172797586; x=1173661586; 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]=20Can=20we=20forget=20LISP,=20please? |Sender:=20; bh=707ZgklieabWkwGlWxy4kzjjVSdEqwnBEgCBng153sw=; b=Sv4AQP1k0cQkQLqTscnf9xBXBhn1LZ05I/JI4KoWm8ioyoL1Ljs5VwoXrWExQ/AJrd5nkiMC VQ6QXD5z0mDwgJNUXXYxFWxy8zupII3XPcv/j6WWXIVKp9Ey5NML4TTV; 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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ram@ietf.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 > Aren't you dismissing an obvious third solution, i.e. the use of > cryptographically bound identities as IDs? It seems to me that LISP > would work rather well with CGAs as in SHIM6? Okay, I need a precise explanation here for me to get any value out of this email. Saying "LISP would work well with CGAs as in SHIM6" could mean so many things. So please enlighten me. >> The second major challenge that I see in LISP is the case >> where a source spoofs the ID of a third party and sends a >> packet from a reachable/valid locator. The ETR needs a >> mechanism to validate the ITR/Locator mapping. > > This is trivial with CGAs. Again, explain. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 01 20:41:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMwlZ-0003KB-7i; Thu, 01 Mar 2007 20:41:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMwlX-0003G6-97 for ram@ietf.org; Thu, 01 Mar 2007 20:40:59 -0500 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMwlV-0001bp-PE for ram@ietf.org; Thu, 01 Mar 2007 20:40:59 -0500 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id ECD6053E1B5; Thu, 1 Mar 2007 20:40:47 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id 6C4VGNZBNslU; Thu, 1 Mar 2007 20:40:32 -0500 (EST) Received: from [124.81.250.42] (unknown [124.81.250.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 127EB53E072; Thu, 1 Mar 2007 20:40:25 -0500 (EST) In-Reply-To: <5.0.0.25.2.20070301101217.0354d080@zircon.juniper.net> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com> <5BE0C06B-0A5F-4057-92EC-D90582B08FB8@bgp.nu> <5.0.0.25.2.20070301101217.0354d080@zircon.juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <718DE6AB-85DF-4E13-8759-D3D507FE82BA@bgp.nu> Content-Transfer-Encoding: 7bit From: "John G. Scudder" Subject: Re: [RAM] Can we forget LISP, please? Date: Fri, 2 Mar 2007 09:40:20 +0800 To: Ross Callon X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ram@ietf.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 Mar 1, 2007, at 11:27 PM, Ross Callon wrote: > My interpretation of John's comment is that he is concerned about > the partial nature of the cache, and not the temporary nature of > the cache. That's as good a summary as any, and I'll also associate myself with Tony's later comment. The corollary is that *if* the LISP encapsulator/decapsulator could be guaranteed to be far enough out on the edge of the network that the working set could reasonably be expected to be small, then this concern would diminish. (Though I'm not sure that helps for high- fanout hosts, e.g. some kinds of server farms.) --John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 00:10:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN013-0002Ji-AG; Fri, 02 Mar 2007 00:09:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN012-0002Jc-3E for ram@iab.org; Fri, 02 Mar 2007 00:09:12 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN00w-0004hz-PU for ram@iab.org; Fri, 02 Mar 2007 00:09:12 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id C740534129; Fri, 2 Mar 2007 00:09:00 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 00:09:00 -0500 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] Architectural comments on draft-farinacci-lisp-00 Date: Fri, 2 Mar 2007 00:08:59 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC0179E968@tayexc14.americas.cpqcorp.net> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Architectural comments on draft-farinacci-lisp-00 Thread-Index: AcdZ8egzk1Dk7cDTTGa4MZd2iqTb2gACWdIgAKMselA= References: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> From: "Bound, Jim" To: "Henderson, Thomas R" , "Dino Farinacci" X-OriginalArrivalTime: 02 Mar 2007 05:09:00.0863 (UTC) FILETIME=[E3B02CF0:01C75C88] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 LISP solution if accepted removes the need to do split ID/LOC for now. Also in my view watching this mail none have answered Brian Carpenters mail on the issues of LOC/ID split and the trade-offs from some time ago. That reinforces for me true split of LOC/ID is really an IRTF effort not an IETF effort and will take a minimum of 5 years. What LISP does is provides an opportunity to view a short term solution to the RAM issues identified within LISP. I for one am not worried about the encapsulation at ITR to ETR and decap at ETR. Additional security can be specified and defense in depth with IPsec VPNs is achievable over a routed network path. Also as LISP states this does not preclude continued work on SHIM6, which I still think is important to move forward. /jim=20 > -----Original Message----- > From: Henderson, Thomas R [mailto:thomas.r.henderson@boeing.com]=20 > Sent: Monday, February 26, 2007 6:27 PM > To: Dino Farinacci > Cc: ram@iab.org > Subject: RE: [RAM] Architectural comments on draft-farinacci-lisp-00 >=20 > =20 >=20 > > -----Original Message----- > > From: Dino Farinacci [mailto:dino@cisco.com] > > Sent: Monday, February 26, 2007 2:03 PM > > To: Henderson, Thomas R > > Cc: Brian E Carpenter; ram@iab.org > > Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 > >=20 > > > I agree with Brian's complaint here; LISP is really about=20 > multiple=20 > > > levels of locators and not really an ID/locator split, based on=20 > > > traditional use of these terms. > >=20 > > LISP is both, just like GSE is. > >=20 >=20 > It's not equivalent to GSE, which actually split the IP=20 > address into ID and locator portions. LISP is an ID/locator=20 > separation (the draft title uses the word separation, but=20 > also uses the word "split" internally) only in the context of=20 > a particular address allocation and routing policy. Again,=20 > this is just terminology, but I think it would be more=20 > precise to define it in terms of multiple locator spaces that=20 > are tunneled over one another, for purposes of core routing=20 > scalability. >=20 > Tom >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 00:13: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 1HN05Z-000535-MK; Fri, 02 Mar 2007 00:13:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN05Y-00052v-MV for ram@ietf.org; Fri, 02 Mar 2007 00:13:52 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN05T-00057p-BO for ram@ietf.org; Fri, 02 Mar 2007 00:13:52 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id CDEA934135; Fri, 2 Mar 2007 00:13:43 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 00:13:43 -0500 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] Can we forget LISP, please? Date: Fri, 2 Mar 2007 00:13:42 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC0179E96A@tayexc14.americas.cpqcorp.net> In-Reply-To: <68F47693-36E2-483A-8B07-C00C3FFC6BA9@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Can we forget LISP, please? Thread-Index: AcdaSodC4JM5uChzT06W0tLJlv2o+QCPtY2g References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com><1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <68F47693-36E2-483A-8B07-C00C3FFC6BA9@nomadiclab.com> From: "Bound, Jim" To: "Pekka Nikander" , "Dino Farinacci" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 02 Mar 2007 05:13:43.0910 (UTC) FILETIME=[8C65B860:01C75C89] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ram@ietf.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 Not sure I agree but do support continued work with SHIM6 but HIP is not going to fly is my view but maybe move all energy to SHIM6 and take what can be taken from HIP. As far as tossing LISP I don't see that on this list at all on the contrary my read is signficant interest and support to keep going. /jim=20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Tuesday, February 27, 2007 3:37 AM > To: Dino Farinacci; Iljitsch van Beijnum > Cc: ram@ietf.org > Subject: Re: [RAM] Can we forget LISP, please? >=20 > Firstly, as I have stated earlier, and tried to outline in=20 > the generix draft, I think we can do basically what LISP=20 > tried to do by proxying SHIM6 or HIP. That should lead to=20 > roughly equal deployment speed. The system might not be as=20 > "simple" as what LISP appears to be, but not necessarily that=20 > complex either. >=20 > Secondly, what I've heard from multiple sources is that=20 > people don't agree on the necessity of getting this out=20 > "quickly". Yes, there is a looming problem, but people seem=20 > to disagree how many years we have time still. Apparently at=20 > least a couple of years, though. >=20 > So, my take on this is that we shouldn't just forget LISP. =20 > IMHO, there are a few good ideas there. However, I still=20 > believe that we should aim for a more "proper" ID/loc split=20 > than what LISP at its current state can provide. IMHO, that=20 > would bring forth multiple benefits in the form of really=20 > upgrading the architecture in the slightly longer run, such=20 > as proper support for all kinds middle boxes (and not just=20 > TRs), ability to better integrated IPv4 and IPv6 (something=20 > which HIP provides today), optimised support for mobile=20 > routers, combined support for host mobility and multi-homing=20 > (HIP does that) and site multi-homing and TE (an open issue,=20 > see Elwyn Davie's very good mail on the arch-d list), etc. >=20 > We should not commit ourselves to any single proposal at this time. =20 > Instead, we should try to understand the strengths and=20 > drawbacks of the different proposals, aiming for something=20 > more comprehensive (but of course not try to boil the oceans). >=20 > It would be a mistake to focus only on the routing table problem. =20 > Given the current looming crisis, we have a great opportunity=20 > to finally upgrade the architecture by adding a proper new=20 > name space, something that Saltzer called for already in 1982. >=20 > --Pekka Nikander >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 00:19: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 1HN0AT-00077u-0h; Fri, 02 Mar 2007 00:18:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN0AS-00077p-8R for ram@ietf.org; Fri, 02 Mar 2007 00:18:56 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN0AJ-0005mS-LN for ram@ietf.org; Fri, 02 Mar 2007 00:18:56 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 1756434126; Fri, 2 Mar 2007 00:18:44 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 00:18:43 -0500 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] Can we forget LISP, please? Date: Fri, 2 Mar 2007 00:18:42 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC0179E96B@tayexc14.americas.cpqcorp.net> In-Reply-To: <45E40ADA.8030804@info.ucl.ac.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Can we forget LISP, please? Thread-Index: AcdaW/eq3fBQo/k9TDeoMqr+4LIpvwCLd5mA References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <45E40ADA.8030804@info.ucl.ac.be> From: "Bound, Jim" To: , "Iljitsch van Beijnum" X-OriginalArrivalTime: 02 Mar 2007 05:18:43.0984 (UTC) FILETIME=[3F416100:01C75C8A] X-Spam-Score: 0.4 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: ram@ietf.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 When we get to LISP 3 DHTs are a good idea Planet Labs has been using them for some time. Much better than DNS for edge routers. But as others have said devil is in the details. In addition I can see how LISP DHTs can help with pre-congestion notification as a note when designed. http://www.planet-lab.org/ /jim =20 > -----Original Message----- > From: Olivier Bonaventure [mailto:Bonaventure@info.ucl.ac.be]=20 > Sent: Tuesday, February 27, 2007 5:42 AM > To: Iljitsch van Beijnum > Cc: ram@ietf.org > Subject: Re: [RAM] Can we forget LISP, please? >=20 > Iljitsch, >=20 > > It looks to me that lisp is nothing more than tunneling packets =20 > > across the DFZ where there is a central mapping database that's =20 > > distributed through ICMP messages. Please, this has to stop. >=20 > I disagree, LISP has the potential of bringing additional=20 > benefits and is worth being considered. >=20 > > Three years ago, 40% > > of the internet melted because routers couldn't keep up=20 > with filling=20 > > their forwarding caches from a LOCALLY AVAILABLE mapping database=20 > > when a worm hit that made hosts send out 15000 packets per second=20 > > with random destination addresses. >=20 > We should not based architectural decisions for the future=20 > internet on implementation problems in the past internet. >=20 > > Caching anywhere else but the source host is a=20 > non-starter. ICMP is=20 > > also completely useless because anyone can fake those. >=20 > ICMP looks to me like an interim solution, let's consider=20 > also lisp 1.5, LISP2, ... >=20 > > What we need is a design that: > >=20 > > 1. Aligns cost with benefit =3D must be done in provider networks, = at=20 > > least at first >=20 > LISP-like solutions could also provide benefits for the=20 > customer networks. For example LISP can allow a stub AS to=20 > control its incoming and outgoing traffic, which can be a=20 > strong incentive for stub ASes to request from their=20 > providers the deployment of LISP-like solutions. >=20 > > 2. Enforces renumberability =3D the locator must be invisible to the = > > end-user 3. Supports the necessary parallelism that allows=20 > scaling to =20 > > arbitrary numbers 4. Doesn't depend on a particular type of=20 > traffic,=20 > > i.e., a million packets to one address works just as well=20 > as a million=20 > > packets to a million different addresses >=20 > The type of traffic to support will be an engineering=20 > decision. For me, it would seem reasonable to optimise a=20 > platform to better support a million packets sent to one=20 > address than a million packets to a million different=20 > addresses, especially at the edge. At the edge, there are few=20 > real applications needing to send packets to millions of destinations. >=20 > > 5. Is less vulnerable to threats than current BGP 6. Supports=20 > > rerouting after failures =3D a single global mapping database isn't = > > enough >=20 > The rerouting after failure is orthogonal for me. To achieve=20 > fast recovery after failures, local solutions are better than=20 > global solutions because they react faster and do not require=20 > a full routing convergence. In fact, tunnels can also be used=20 > to provide fast failover of BGP peering links in case of=20 > failures, see: > http://www.info.ucl.ac.be/people/OBO/papers/f41-bonaventure.pdf >=20 > > The way I see it, this means that we must come up with a protocol =20 > > that floods mapping state throughout the network but in a way that =20 > > allows N devices to each hold 1/N part of the full global=20 > state and =20 > > process 1/N of the global updates. >=20 > You basically propose to use a DHT to distribute the mapping,=20 > this is one of the possible implementations of the mapping. >=20 > > This protocol needs good security and quick reaction to outages,=20 > > which are things that current BGP doesn't do adequately. But since=20 > > there are no users yet, we get to do a greenfield design=20 > so it should=20 > > be doable. >=20 > I think that greenfield design could be an objective for version 2. >=20 >=20 >=20 > Olivier >=20 > -- > CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/~obo >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 00:20: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 1HN0CB-0007SS-Ce; Fri, 02 Mar 2007 00:20:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN0C9-0007SC-Ft; Fri, 02 Mar 2007 00:20:41 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN0C4-0005wn-5F; Fri, 02 Mar 2007 00:20:41 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id A4A2134145; Fri, 2 Mar 2007 00:20:35 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 00:20:35 -0500 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: [arch-d] Re: [RAM] IRTF RRG: call for participation Date: Fri, 2 Mar 2007 00:20:33 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC0179E96C@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Re: [RAM] IRTF RRG: call for participation Thread-Index: AcdaimuhwMlr3tVjSEGGvR6sRsxtlwCAAIYQ References: From: "Bound, Jim" To: "Lixia Zhang" , "Romascanu, Dan ((Dan))" X-OriginalArrivalTime: 02 Mar 2007 05:20:35.0545 (UTC) FILETIME=[81C03C90:01C75C8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Tony Li , ram@ietf.org, architecture-discuss@ietf.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 but it is scheduled on a saturday :--). /jim=20 > -----Original Message----- > From: Lixia Zhang [mailto:lixia@CS.UCLA.EDU]=20 > Sent: Tuesday, February 27, 2007 11:14 AM > To: Romascanu, Dan ((Dan)) > Cc: Tony Li; ram@ietf.org; architecture-discuss@ietf.org > Subject: [arch-d] Re: [RAM] IRTF RRG: call for participation >=20 >=20 > On Feb 27, 2007, at 3:15 AM, Romascanu, Dan ((Dan)) wrote: >=20 > > Is this meeting open to everybody, open to the IETF meeting=20 > attendees,=20 > > not open? > > > > Dan >=20 > Yes this RRG meeting is open to everyone. We need the=20 > community's joint effort to develop a good architectural solution. > We would like to encourage people to register for IETF as=20 > IETF resources are being used to provide the room, projector,=20 > network access, etc. for this meeting. However for those who=20 > do not plan to attend IETF otherwise, it seems unpractical to=20 > require them to register for IETF. >=20 > >> -----Original Message----- > >> From: Tony Li [mailto:tli@cisco.com] > >> Sent: Tuesday, February 27, 2007 12:01 AM > >> To: architecture-discuss@ietf.org; ram@ietf.org > >> Cc: Lixia Zhang > >> Subject: [RAM] IRTF RRG: call for participation > >> > >> > >> Hi, > >> > >> The Routing Research Group of the IRTF will be holding a one-day=20 > >> seminar in Prague on March 17th to discuss the=20 > architectural issues=20 > >> confronting the Internet. This meeting will be held in=20 > conjunction=20 > >> with, and just prior to, the upcoming IETF meeting. > >> > >> We would like to invite researchers to participate in this seminar=20 > >> and in the ongoing activities of the RRG. We are calling for=20 > >> contributions and talks on architectural problem analysis and=20 > >> proposed alternative routing and addressing architectures for the=20 > >> Internet. > >> > >> Please contact the RRG co-chairs, Lixia Zhang and myself,=20 > if you are=20 > >> interested in giving a presentation. Currently scheduled=20 > talks can=20 > >> be found at=20 > http://www1.tools.ietf.org/group/irtf/trac/wiki/RRG. If=20 > >> you are making a presentation, we do ask that your=20 > material (papers,=20 > >> slides, etc.) be made available via the Internet prior to the=20 > >> seminar. > >> > >> Regards, > >> Lixia & Tony > >> > >> _______________________________________________ > >> RAM mailing list > >> RAM@iab.org > >> https://www1.ietf.org/mailman/listinfo/ram > >> >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 00:33:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN0Nm-0008At-65; Fri, 02 Mar 2007 00:32:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN0Nk-00087O-PQ for ram@ietf.org; Fri, 02 Mar 2007 00:32:40 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN0Nf-0007Kg-7O for ram@ietf.org; Fri, 02 Mar 2007 00:32:40 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id B8EB53410B; Fri, 2 Mar 2007 00:32:34 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 00:32:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RAM] Can we forget LISP, please? Date: Fri, 2 Mar 2007 00:32:32 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC0179E970@tayexc14.americas.cpqcorp.net> In-Reply-To: <5.0.0.25.2.20070301101217.0354d080@zircon.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Can we forget LISP, please? Thread-Index: AcdcFlKlrAHYqvRPQLmDufL9j75dQAAdZsdQ References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com><1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com><03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com><5BE0C06B-0A5F-4057-92EC-D90582B08FB8@bgp.nu> <5.0.0.25.2.20070301101217.0354d080@zircon.juniper.net> From: "Bound, Jim" To: "Ross Callon" , "Eliot Lear" , "John G. Scudder" X-OriginalArrivalTime: 02 Mar 2007 05:32:34.0681 (UTC) FILETIME=[2E63AE90:01C75C8C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: ram@ietf.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="===============1255823618==" Errors-To: ram-bounces@iab.org This is a multi-part message in MIME format. --===============1255823618== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75C8C.2DBB0E9D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75C8C.2DBB0E9D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ITR and ETR are very close to the edges. I don't see how large or small networks affects the cache for parsing with current technology? did you mean the AS domains within the site or network path for small or large? =20 /jim ________________________________ From: Ross Callon [mailto:rcallon@juniper.net]=20 Sent: Thursday, March 01, 2007 10:27 AM To: Eliot Lear; John G. Scudder Cc: ram@ietf.org Subject: Re: [RAM] Can we forget LISP, please? =09 =09 At 12:07 PM 3/1/2007 +0100, Eliot Lear wrote: =09 Oh please. =09 Hmm. The BGP RIB is a sort of a cache. Huh? How do you figure? Let me rephrase that: No, it's not. A cache is merely a temporary store. So how about responding to the meat of Dino's proposal rather than being pedantic? My understanding of a cache is that it is a temporary store=20 of **PART** of the database, and not all of the database. My interpretation of John's comment is that he is concerned about the partial nature of the cache, and not the temporary nature of the cache.=20 =09 From Wikipedia: "Caches have proven to be extremely effective in many areas=20 of computing because access patterns in typical computer=20 applications have locality of reference." =09 Others may be able to comment better than I on the experience=20 with cache based routers. My impression is that these are okay very close to the edge of small networks, but have experienced=20 significant problems in core service providers.=20 =09 Ross=20 ------_=_NextPart_001_01C75C8C.2DBB0E9D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
ITR and ETR are very close to the edges.  = I don't see=20 how large or small networks affects the cache for parsing with current=20 technology?  did you mean the AS domains within the site or network = path=20 for small or large?
 
/jim

From: Ross Callon = [mailto:rcallon@juniper.net]=20
Sent: Thursday, March 01, 2007 10:27 AM
To: Eliot = Lear;=20 John G. Scudder
Cc: ram@ietf.org
Subject: Re: = [RAM] Can we=20 forget LISP, please?

At 12:07 PM 3/1/2007 +0100, Eliot Lear wrote:
Oh please.

Hmm. The BGP = RIB is a sort=20 of a cache.

Huh?  How do you=20 figure?

Let me rephrase that:  No, it's=20 not.

A cache is merely a temporary store.  So = how about=20 responding to the meat of Dino's proposal rather than being=20 pedantic?

My understanding of a cache is that it is a=20 temporary store
of **PART** of the database, and not all of the = database.=20 My
interpretation of John's comment is that he is concerned = about
the=20 partial nature of the cache, and not the temporary nature of
the = cache.=20

From Wikipedia:
    "Caches have proven to = be=20 extremely effective in many areas
    of computing = because=20 access patterns in typical computer
    = applications have=20 locality of = reference."

Others may be=20 able to comment better than I on the experience
with cache based = routers.=20 My impression is that these are okay
very close to the edge of = small=20 networks, but have experienced
significant problems in core = service=20 providers.

Ross ------_=_NextPart_001_01C75C8C.2DBB0E9D-- --===============1255823618== 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 --===============1255823618==-- From ram-bounces@iab.org Fri Mar 02 00:39: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 1HN0Tr-0007Ov-Pl; Fri, 02 Mar 2007 00:38:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN0Tr-0007Oq-59 for ram@ietf.org; Fri, 02 Mar 2007 00:38:59 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN0Tl-0008VP-RR for ram@ietf.org; Fri, 02 Mar 2007 00:38:59 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 8155534113; Fri, 2 Mar 2007 00:38:53 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 00:38:53 -0500 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] Can we forget LISP, please? Date: Fri, 2 Mar 2007 00:38:51 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC0179E972@tayexc14.americas.cpqcorp.net> In-Reply-To: <43F926FF-75BC-42DB-B49C-DED18AE02283@lilacglade.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Can we forget LISP, please? Thread-Index: AcdcGwQqu+9UfRGvR6iayaKoXLXjlQAcTvSg References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com><1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com><03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com><82C79563-790E-4E8C-8EE8-074429B42B5E@muada.com><9021D990-01EE-48DC-AEA6-7DD2DEF34ECA@cisco.com> <43F926FF-75BC-42DB-B49C-DED18AE02283@lilacglade.org> From: "Bound, Jim" To: "Margaret Wasserman" , "Dino Farinacci" X-OriginalArrivalTime: 02 Mar 2007 05:38:53.0429 (UTC) FILETIME=[10240A50:01C75C8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ram@ietf.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 don't agree with the way you say it. A positive view is LISP provides another level of indirection, which is entirely OK to identify short term network computer science solutions. LISP moved the locator distribution to the edge and this is a good design center to alleviate a segment of the problems identified within the RAM processes, and I think will not cause to much additional operator management overhead or cost. I am not concerned about tunneling. Everyone designing most additions at any IP Reference Model layer are using tunnels it is life, we will deal with it as IT vendors, it will perform, and scale. The security ramifications I believe will be resolved though I am absolutely against use of CGA but not going there for now we have far more important discussions before we go off on that thread, at least for me. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@lilacglade.org]=20 > Sent: Thursday, March 01, 2007 11:01 AM > To: Dino Farinacci > Cc: ram@ietf.org > Subject: Re: [RAM] Can we forget LISP, please? >=20 >=20 > On Feb 28, 2007, at 8:47 PM, Dino Farinacci wrote: >=20 > >> You can of course always find more address bits by adding extra=20 > >> tunnel headers, which also helps with keeping the whole thing more=20 > >> backward compatible. This could actually work, but then=20 > we're back at=20 > >> how to find outer tunnel addresses (LOCs) to go along with inner=20 > >> tunnel addresses (IDs). > > > > Yep. >=20 > Exactly. >=20 > Regardless of whether we use an IP-in-IP tunnel approach, or=20 > an IP-in- LISP approach, or any other tiered routing=20 > approach, we have the same mapping problem. Given a=20 > non-local, non-globally-routable end-point identifier, how do=20 > we find a globally routable locator so that we can get our=20 > packets there? >=20 > Without a mapping mechanism that meets application=20 > requirements and scales better than current IP routing, we're=20 > just moving the problem around. >=20 > Margaret >=20 >=20 >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 02:25:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN26W-00057Q-2Q; Fri, 02 Mar 2007 02:23:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN26T-00057H-OM for ram@ietf.org; Fri, 02 Mar 2007 02:22:57 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN26O-00051P-7k for ram@ietf.org; Fri, 02 Mar 2007 02:22:57 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3DD8910FE7A; Fri, 2 Mar 2007 08:22:51 +0100 (CET) Received: from [163.117.203.81] (unknown [163.117.203.81]) by smtp02.uc3m.es (Postfix) with ESMTP id 83C1B10FE46; Fri, 2 Mar 2007 08:22:50 +0100 (CET) In-Reply-To: <6B864A95-1728-4761-8A58-5ACD3F0BE7DB@cisco.com> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <60C4A248E730F249990993E3B9BD44D80322B119@xmb-sjc-218.amer.cisco.com> <6B864A95-1728-4761-8A58-5ACD3F0BE7DB@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8a27c530ddfa3d61ec1fab05812d7ded@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Can we forget LISP, please? Date: Fri, 2 Mar 2007 08:24:29 +0100 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ram@ietf.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 Dino, El 02/03/2007, a las 2:06, Dino Farinacci escribi=F3: >> Aren't you dismissing an obvious third solution, i.e. the use of >> cryptographically bound identities as IDs? It seems to me that LISP >> would work rather well with CGAs as in SHIM6? > > Okay, I need a precise explanation here for me to get any value out of=20= > this email. Saying "LISP would work well with CGAs as in SHIM6" could=20= > mean so many things. So please enlighten me. > Darrel identified two main security aspects that he described as: > The first, as you mention above, is the ability to 'fake' ICMP request > packets. It is important to note that ICMP isn't the problem, LISP > could have picked a new IP protocol number and packet, used UDP, or = any > number of things, but the problem would remain. When a new mapping > request packet arrives at the ETR, the ETR cannot just process this > packet without some way to validate that this packet came from the > source in the source address field. Rate limiting these packets is = not > a solution due to the inability to classify good from bad by just > looking at the initial packet. > There are two ways to solve this problem today* (maybe more...?), one=20= > is > a multi-packet exchange that uses nonce values and return routability=20= > to > verify the source. TCP syn-cookies is an example of this type of > approach. The second is some sort of proof of identity using > symmetrical keying. Both of these approaches can be implemented in = the > dataplane, which will be a requirement to avoid the DoS. > > > The second major challenge that I see in LISP is the case where a=20 > source > spoofs the ID of a third party and sends a packet from a=20 > reachable/valid > locator. The ETR needs a mechanism to validate the ITR/Locator=20 > mapping. > (Today this is done with return routability, which makes it very > difficult to fake establishment of TCP connections without being a = MITM > attack, or L2 spoofing). Some sort of cert based ID/Loc mapping > database needs to exist for the ETR to be able to use to verify that=20= > the > source ID/Loc is valid. > > There may be many other security issues out there, but if we can solve > these two and not break LISP, IMHO we'll have a good foundation to = work > on. As i see it, both are about validating the source of the packet,=20 wwhether the source locator or the source identifier In order to validate that the source address contained in the source=20 address field of the packet, you could use CGAs as the source address. since CGA are derived from a public key, containing some form of=20 signature inside the packet itself generated with the associated=20 private key would prove that the actual owner of the source address did=20= generated the packet. i can go further into details if you are itnerested, but this is the=20 main idea i think Regards, marcelo hope this helps >>> The second major challenge that I see in LISP is the case >>> where a source spoofs the ID of a third party and sends a >>> packet from a reachable/valid locator. The ETR needs a >>> mechanism to validate the ITR/Locator mapping. >> >> This is trivial with CGAs. > > Again, explain. > > Dino > > _______________________________________________ > 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 Fri Mar 02 03:33: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 1HN3CF-0002uM-KS; Fri, 02 Mar 2007 03:32:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN3CE-0002uB-A3 for ram@iab.org; Fri, 02 Mar 2007 03:32:58 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN3CC-00082X-Pq for ram@iab.org; Fri, 02 Mar 2007 03:32:58 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0F824212D4D; Fri, 2 Mar 2007 10:32:55 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B9EF9212D48; Fri, 2 Mar 2007 10:32:54 +0200 (EET) In-Reply-To: <816DD9299957E547B5D758D7F977D6DC0179E968@tayexc14.americas.cpqcorp.net> References: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> <816DD9299957E547B5D758D7F977D6DC0179E968@tayexc14.americas.cpqcorp.net> 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: Pekka Nikander Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Fri, 2 Mar 2007 10:32:51 +0200 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Jim, A few quick comments: 1. Personally, I believe that we can do with SHIM6 (or HIP) what LISP aims to do either as easily, or at least almost as easily, as a fully developed version of LISP would do. We try to outline that in the PASH draft, http://www.ietf.org/internet-drafts/draft-nikander-ram-pash-00.txt 2. I started to analyse the design space related to id/loc split. However, given the time limits I didn't get that far, yet. The current version, mostly bare bones, is the ILSE draft: http://www.ietf.org/internet-drafts/draft-nikander-ram-ilse-00.txt Based on my/our argumentation therein, my tentative conclusions are the following: We should go for a full-blown but simplified id/loc split, probably based on SHIM6. We could start by simplifying SHIM6 quite a lot, e.g. by forgetting e.g. even SHIM6 multi-homing features, but still use the protocol and security framework, for *forward* compatibility. As far as I can see, running over IPv4 should not be a problem here; using IPv4-address-like identifiers may be a real challenge, but might be solvable for very early deployment, depending on your trust model. Starting from LISP, you could get there by a) using the SHIM6 protocol instead of ICMP, b) using SHIM6 tags instead of tunnelling (but this is not important), c) using CGAS as identifiers, and d) adopting the LISP 1.5 deployment approach, basically meaning separate routing infrastructures for IPv4 (locators) and IPv6 (identifiers). But I don't know if that was the best way, or even a good one. Alternatively, you could start from PASH or PSHIM6, and end up at pretty much the same target. Replacing the IPv6 routing infra with a DHT or similar would allow you to use ORCHIDs too, enabling HIP as a (forward compatible) option. Trying to crystallise my standing: Removing the need for id/loc split for now would be a BAD thing for the Internet. Read Mark Handley's "Why the Internet just works." If we remove the energy that the community now has through yet another ugly pat^H^H^H^H^H point solution, I doubt we will ever get another chance to implement the id/loc split. But then, losing the current opportunity might be a good thing for the clean slate approaches. :-) --Pekka Nikander On 2 Mar 2007, at 07:08, Bound, Jim wrote: > LISP solution if accepted removes the need to do split ID/LOC for now. > Also in my view watching this mail none have answered Brian Carpenters > mail on the issues of LOC/ID split and the trade-offs from some time > ago. That reinforces for me true split of LOC/ID is really an IRTF > effort not an IETF effort and will take a minimum of 5 years. What > LISP > does is provides an opportunity to view a short term solution to > the RAM > issues identified within LISP. I for one am not worried about the > encapsulation at ITR to ETR and decap at ETR. Additional security can > be specified and defense in depth with IPsec VPNs is achievable over a > routed network path. Also as LISP states this does not preclude > continued work on SHIM6, which I still think is important to move > forward. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 03:52: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 1HN3UZ-0006FN-Pu; Fri, 02 Mar 2007 03:51:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN3UX-0006Eb-Mj for ram@iab.org; Fri, 02 Mar 2007 03:51:53 -0500 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 1HN3UU-0002wn-6z for ram@iab.org; Fri, 02 Mar 2007 03:51:53 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l228n67f016684; Fri, 2 Mar 2007 10:49:27 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 10:51:11 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 10:51:11 +0200 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] Terminology: ID/Locator split Date: Fri, 2 Mar 2007 10:51:10 +0200 Message-ID: In-Reply-To: <45E729B0.80303@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Terminology: ID/Locator split Thread-Index: AcdcOClj1ow9JdUYQeeLDlg7nkoKTQAbpMqg References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> <45E729B0.80303@employees.org> From: To: , X-OriginalArrivalTime: 02 Mar 2007 08:51:11.0514 (UTC) FILETIME=[ED6017A0:01C75CA7] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Scott W Brim wrote: >On 03/01/2007 13:39 PM, RJ Atkinson wrote: >> 1) a "Locator" which is ONLY used for packet forwarding >> and is NEVER visible above the network-layer >> (e.g. no name ever used for network-layer packet forwarding >> is ever visible to TCP) >> && >>=20 >> 2) an "Identifier" that is used by the transport-layer >> (e.g. in TCP session state, such as TCP pseudo-header checksum), >> might be used above the transport-layer, and >> is NEVER used for network-layer packet forwarding. > >I don't get to stop by this party very often, but have you=20 >agreed that there a requirement that there be a single=20 >"identifier" down in the transport layer? The last line of=20 >(2) is certainly true. I'm wondering about the 2nd line. > I'd like to question this certainty that you have on the NEVER in 2). We have good evidence on usability of flat routing on e.g. campus level (Ethernet, rbridges). Currently IP address is used as a flat identifier for last hop forwarding within a subnet. It seems conceivable that the "network layer" actually ends at the last hop router, as the topology information in the IP address is exhausted, as the last hop forwarding is done on the destination interface identifier.=20 Regards, Jarno _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 03:56: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 1HN3Ya-0008VY-Ba; Fri, 02 Mar 2007 03:56:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN3YZ-0008VR-K9 for ram@iab.org; Fri, 02 Mar 2007 03:56:03 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN3YU-0003t6-Bw for ram@iab.org; Fri, 02 Mar 2007 03:56:03 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B7BC2212D4D; Fri, 2 Mar 2007 10:55:57 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7DB68212D48; Fri, 2 Mar 2007 10:55:57 +0200 (EET) In-Reply-To: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <90D707E7-1292-4A9C-A424-28229E5EA77C@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] Terminology: ID/Locator split Date: Fri, 2 Mar 2007 10:55:53 +0200 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Ran, > In some off-list conversations, it seems that there > are varying definitions for the phrase "ID-Locator split". > I suspect the variance in definitions for that phrase is > causing some confusion in discussions on this list. I agree with the differences in the use of the term is causing confusion. > To my mind, when one talks about an "ID/Locator split", > an essential property is that one has both: > > 1) a "Locator" which is ONLY used for packet forwarding > and is NEVER visible above the network-layer > (e.g. no name ever used for network-layer packet forwarding > is ever visible to TCP) > && > > 2) an "Identifier" that is used by the transport-layer > (e.g. in TCP session state, such as TCP pseudo-header checksum), > might be used above the transport-layer, and > is NEVER used for network-layer packet forwarding. According to my analysis, there are three "flavours" of the id/loc split, as outlined in Section 2 of http://www.ietf.org/internet- drafts/draft-nikander-ram-ilse-00.txt: > A. The separation may be implemented above the current > transport > layer, mainly TCP and UDP. In practise, many > applications do > implement a primitive kind of the separation already > themselves. In theory, a library could implement the > separation, giving legacy applications the illustration of > them being still connected to stable IP locators while in > practise using some sort of identifiers. > > B. The separation may be implemented at or below the transport > (i.e. below the socket API) but above the routing part of > the > IP layer. There are a plenty of proposals in this space, > including SCTP extensions [10], the Host Identity Protocol > (HIP) [3], and the SHIM6 protocol [6]. > > C. The separation may be implemented below the host-part of the > IP layer. Again, there are a number of proposals in this > space, of which the [9] has recently gained some attention. Of these, the middle one (B) is closest to the traditional use of the term [Chiappa]. And there, only some of the proposed solutions, like HIP and SHIM6, really match with the original idea. At least those that do match seem to comply with your definition, but perhaps also others. --Pekka Nikander [Chiappa] Chiappa, J., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", URL http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 03:59:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN3bb-0001cD-EB; Fri, 02 Mar 2007 03:59:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN3bY-0001bw-Td for ram@iab.org; Fri, 02 Mar 2007 03:59:08 -0500 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN3bX-0004OF-Ec for ram@iab.org; Fri, 02 Mar 2007 03:59:08 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l228x6E7118706 for ; Fri, 2 Mar 2007 08:59:06 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l228x6rl1216758 for ; Fri, 2 Mar 2007 08:59:06 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l228x574026467 for ; Fri, 2 Mar 2007 08:59:05 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l228x5LW026451; Fri, 2 Mar 2007 08:59:05 GMT Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA356674; Fri, 2 Mar 2007 09:59:04 +0100 Message-ID: <45E7E758.9030704@zurich.ibm.com> Date: Fri, 02 Mar 2007 09:59:04 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] Terminology: ID/Locator split References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> In-Reply-To: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 I've already expressed my concern that the word "split" is wrong in itself for many of the solutions being considered. What we have in reality today are context- dependent locators, which in some contexts are used as identifiers for transport, security, applications or network management. The question really is whether we embrace this architecturally (which shim6 and lisp both do) or whether we try to change it by abolishing the context dependency (which is what a true split would do). Brian On 2007-03-01 19:39, RJ Atkinson wrote: > > In some off-list conversations, it seems that there > are varying definitions for the phrase "ID-Locator split". > I suspect the variance in definitions for that phrase is > causing some confusion in discussions on this list. > > To my mind, when one talks about an "ID/Locator split", > an essential property is that one has both: > > 1) a "Locator" which is ONLY used for packet forwarding > and is NEVER visible above the network-layer > (e.g. no name ever used for network-layer packet forwarding > is ever visible to TCP) > && > > 2) an "Identifier" that is used by the transport-layer > (e.g. in TCP session state, such as TCP pseudo-header checksum), > might be used above the transport-layer, and > is NEVER used for network-layer packet forwarding. > > > If other folks have CRISP and CLEAR alternative definitions > for "ID-Locator split", then it might be interesting to know > precisely what those alternative definitions are... > > Ran > > > > _______________________________________________ > 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 Fri Mar 02 08:53: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 1HN8Ad-0008Gf-A8; Fri, 02 Mar 2007 08:51:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN8Ac-0008GX-2Y for ram@iab.org; Fri, 02 Mar 2007 08:51:38 -0500 Received: from [207.179.9.76] (helo=smtp1.extremenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN8Aa-0005ao-PN for ram@iab.org; Fri, 02 Mar 2007 08:51:38 -0500 Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 286BD7946; Fri, 2 Mar 2007 05:51:26 -0800 (PST) In-Reply-To: References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> <45E729B0.80303@employees.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2AB7745A-7C31-47F4-82B0-C05EF21109F8@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Terminology: ID/Locator split Date: Fri, 2 Mar 2007 08:51:25 -0500 To: X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 2 Mar 2007, at 03:51, wrote: > Scott W Brim wrote: >> On 03/01/2007 13:39 PM, RJ Atkinson wrote: >>> 1) a "Locator" which is ONLY used for packet forwarding >>> and is NEVER visible above the network-layer >>> (e.g. no name ever used for network-layer packet forwarding >>> is ever visible to TCP) >>> && >>> >>> 2) an "Identifier" that is used by the transport-layer >>> (e.g. in TCP session state, such as TCP pseudo-header checksum), >>> might be used above the transport-layer, and >>> is NEVER used for network-layer packet forwarding. >> >> I don't get to stop by this party very often, but have you >> agreed that there a requirement that there be a single >> "identifier" down in the transport layer? The last line of >> (2) is certainly true. I'm wondering about the 2nd line. >> > > I'd like to question this certainty that you have on the NEVER in 2). > We have good evidence on usability of flat routing on e.g. campus > level > (Ethernet, rbridges). Currently IP address is used as a flat > identifier > for last hop forwarding within a subnet. Ethernet is not at the "network-layer", which was an important and deliberate part of my original statement. The question I posed, however, is not whether "flat routing works", or whether one wants layers above the network-layer entangled in IP routing, but what one means by various terms. As a matter of definition, a SPLIT between Identifier and Locator should mean that the Identifier used above the network-layer is NOT used for routing, since the Locator is used for routing. Not splitting them is a legitimate architectural choice. We have that today (e.g. TCP session state includes the IPv4 address used for routing packets). Clearly, within some limits, the current approach has worked suitably well for some years. > It seems conceivable that the > "network layer" actually ends at the last hop router, as the topology > information in the IP address is exhausted, as the last hop forwarding > is done on the destination interface identifier. I'm not quite sure what you mean. If you mean that an Identifier might be part of a last-hop ND/ARP cache lookup, that would not conflict with my original definition above. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 08:58:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN8Gn-0006Ek-Qe; Fri, 02 Mar 2007 08:58:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN8Gm-0006Ec-6w for ram@iab.org; Fri, 02 Mar 2007 08:58:00 -0500 Received: from [207.179.9.76] (helo=smtp1.extremenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN8Gh-0007EI-RB for ram@iab.org; Fri, 02 Mar 2007 08:58:00 -0500 Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id C606B7946; Fri, 2 Mar 2007 05:57:54 -0800 (PST) In-Reply-To: <90D707E7-1292-4A9C-A424-28229E5EA77C@nomadiclab.com> References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> <90D707E7-1292-4A9C-A424-28229E5EA77C@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5CBBBB37-FF7F-4247-BE8B-18E461187F93@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Terminology: ID/Locator split Date: Fri, 2 Mar 2007 08:57:53 -0500 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 2 Mar 2007, at 03:55, Pekka Nikander wrote: > According to my analysis, there are three "flavours" of the id/loc > split, as outlined in Section 2 of http://www.ietf.org/internet- > drafts/draft-nikander-ram-ilse-00.txt: > >> A. The separation may be implemented above the current >> transport >> layer, mainly TCP and UDP. In practise, many >> applications do >> implement a primitive kind of the separation already >> themselves. In theory, a library could implement the >> separation, giving legacy applications the illustration of >> them being still connected to stable IP locators while in >> practise using some sort of identifiers. >> >> B. The separation may be implemented at or below the transport >> (i.e. below the socket API) but above the routing part >> of the >> IP layer. There are a plenty of proposals in this space, >> including SCTP extensions [10], the Host Identity Protocol >> (HIP) [3], and the SHIM6 protocol [6]. >> >> C. The separation may be implemented below the host-part of >> the >> IP layer. Again, there are a number of proposals in this >> space, of which the [9] has recently gained some attention. > > Of these, the middle one (B) is closest to the traditional use of > the term [Chiappa]. I think the term originally comes from JNC. I first heard it from him in person. To be honest, I don't think that either A or C strictly comply with his definition. And I don't think that having a Locator/Identifier split is a necessity to address the issues on this list. There are a continuum of approaches that might be useful to consider. It would actually HELP the discussion -- and likely help some of the non-ID/Locator Split proposals if we did not mis-use JNC's original (clearer) terminology, IMHO. Some folks seem to think that an idea won't be seriously entertained unless it is "called" an ID/Locator split. I think it would be helpful if folks believed that all serious proposals would be considered, regardless of what technical approach the proposal undertook (and regardless of what class of approach it happens to fall into). :-) > And there, only some of the proposed solutions, like HIP and SHIM6, > really match with the original idea. At least those that do match > seem to comply with your definition, but perhaps also others. I would agree that HIP complies. I am doubtful about SHIM6, since one has a single namespace that is overloaded for both routing and identity. SHIM6 seems to be "NAT inside the host" -- again that's not necessarily bad, just trying to be a clear description of the proposal. Cheers, Ran PS: You get bonus points for citing JNC's online paper. :-) > --Pekka Nikander > > [Chiappa] Chiappa, J., "Endpoints and Endpoint Names: A Proposed > Enhancement to the Internet Architecture", > URL http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 09:02: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 1HN8KN-00084b-Gg; Fri, 02 Mar 2007 09:01:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN8KM-00084Q-AA for ram@iab.org; Fri, 02 Mar 2007 09:01:42 -0500 Received: from [207.179.9.76] (helo=smtp1.extremenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN8KL-0007yI-1L for ram@iab.org; Fri, 02 Mar 2007 09:01:42 -0500 Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 2CAEE7947; Fri, 2 Mar 2007 06:01:38 -0800 (PST) In-Reply-To: <45E7E758.9030704@zurich.ibm.com> References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> <45E7E758.9030704@zurich.ibm.com> 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 Subject: Re: [RAM] Terminology: ID/Locator split Date: Fri, 2 Mar 2007 09:01:36 -0500 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 2 Mar 2007, at 03:59, Brian E Carpenter wrote: > I've already expressed my concern that the word "split" > is wrong in itself for many of the solutions being > considered. Agreed. > What we have in reality today are context- > dependent locators, which in some contexts are used as > identifiers for transport, security, applications or network > management. Agreed. > The question really is whether we embrace > this architecturally (which shim6 and lisp both do) > or whether we try to change it by abolishing the > context dependency (which is what a true split would > do). I don't think LISP does. As near as I can tell, LISP separates the routing space into 2 distinct pieces -- so to me LISP looks like a "Multiple Locator" solution rather than a "Identifier/Locator Split". In particular, with LISP the transport session state still includes location information (albeit not all of the location information), which seems to disqualify it from the "ID/Locator Split" category. As I've said in other notes, I don't think that the solution necessarily requires a strict "ID/Locator Split". I do think that clear conversation is assisted by being crisp and clear in how one describes various proposals' architectural approach. Thanks, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 09:33: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 1HN8og-0005cV-In; Fri, 02 Mar 2007 09:33:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN8of-0005Zd-S8; Fri, 02 Mar 2007 09:33:01 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN8od-0004ZF-88; Fri, 02 Mar 2007 09:33:01 -0500 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 6262995; Fri, 02 Mar 2007 09:32:58 -0500 In-Reply-To: <45E83378.9040709@isi.edu> References: <816DD9299957E547B5D758D7F977D6DC0179E96C@tayexc14.americas.cpqcorp.net> <45E83378.9040709@isi.edu> 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: [arch-d] Re: [RAM] IRTF RRG: call for participation Date: Fri, 2 Mar 2007 09:32:40 -0500 To: Joe Touch X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Tony Li , ram@ietf.org, Lixia Zhang , architecture-discuss@ietf.org, "Bound, Jim" , Chris Morrow 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 Hello; On Mar 2, 2007, at 9:23 AM, Joe Touch wrote: > > > Chris Morrow wrote: >> >> On Mar 2, 2007, at 12:20 AM, Bound, Jim wrote: >> >>> but it is scheduled on a saturday :--). >>> >> >> but it's important... > > There have been various previous discussions on the issue of holding > side meetings before/after the IETF. It's already a week long, and, > given sufficient planning, there could have been a slot or two where > these issues could have been scheduled. > > This meeting may be important in the abstract, but being promoted this > late means that anyone with substantial flight plans is unlikely to > attend. If it's important to have, it's important to schedule in a way > that makes it clear to the community that it's a priority to attend. +1 > > Announcing this late and not giving it 'real' slots during the meeting > (couldn't Friday have been cleared?) isn't the best way to achieve > that > goal, IMO. > Friday already has MBONE Deployment and the Routing Area Working Group WG on top of each other; please do not add a third. Regards Marshall > Joe > > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 09:56: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 1HN99q-0000k1-DK; Fri, 02 Mar 2007 09:54:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN99p-0000j5-8l; Fri, 02 Mar 2007 09:54:53 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN99o-00089l-2g; Fri, 02 Mar 2007 09:54:53 -0500 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 6263083; Fri, 02 Mar 2007 09:54:51 -0500 In-Reply-To: <45E8377D.3010800@isi.edu> References: <816DD9299957E547B5D758D7F977D6DC0179E96C@tayexc14.americas.cpqcorp.net> <45E83378.9040709@isi.edu> <45E8377D.3010800@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44AABF45-3F79-4052-8AF1-F6A3AC312491@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [arch-d] Re: [RAM] IRTF RRG: call for participation Date: Fri, 2 Mar 2007 09:54:40 -0500 To: Joe Touch X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Tony Li , ram@ietf.org, Lixia Zhang , architecture-discuss@ietf.org, "Bound, Jim" , Chris Morrow 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 Hello; On Mar 2, 2007, at 9:41 AM, Joe Touch wrote: > > > Marshall Eubanks wrote: > ... >>> Announcing this late and not giving it 'real' slots during the >>> meeting >>> (couldn't Friday have been cleared?) isn't the best way to >>> achieve that >>> goal, IMO. >> >> Friday already has MBONE Deployment and the Routing Area Working >> Group >> WG on top of each other; >> please do not add a third. > > FWIW, I was suggesting clearing it, not adding to it. I know, but good luck to that at this date; as it is, Dino Farinacci is hoping to present in both meetings and I have been unable to get either moved. Regards Marshall > > Joe > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 10:00: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 1HN9F3-0004rt-7V; Fri, 02 Mar 2007 10:00:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN9F2-0004ro-Ka for ram@ietf.org; Fri, 02 Mar 2007 10:00:16 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN9Ex-0000SQ-9b for ram@ietf.org; Fri, 02 Mar 2007 10:00:16 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 0B4FD3403E; Fri, 2 Mar 2007 10:00:14 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 10:00:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Can we forget LISP, please? Date: Fri, 2 Mar 2007 10:00:10 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC0179EB1B@tayexc14.americas.cpqcorp.net> In-Reply-To: <8a27c530ddfa3d61ec1fab05812d7ded@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Can we forget LISP, please? Thread-Index: Acdcm+fFYIaCMO/gQryafLXnreftBwAPhjWw References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com><60C4A248E730F249990993E3B9BD44D80322B119@xmb-sjc-218.amer.cisco.com><6B864A95-1728-4761-8A58-5ACD3F0BE7DB@cisco.com> <8a27c530ddfa3d61ec1fab05812d7ded@it.uc3m.es> From: "Bound, Jim" To: "marcelo bagnulo braun" , "Dino Farinacci" X-OriginalArrivalTime: 02 Mar 2007 15:00:10.0944 (UTC) FILETIME=[79810400:01C75CDB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ram@ietf.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 Other options for LISP are deep packet inspection being deployed today = on the market by very capable vendors, likewise Intrusion = Detection/Prevention products. /jim=20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Friday, March 02, 2007 2:24 AM > To: Dino Farinacci > Cc: ram@ietf.org > Subject: Re: [RAM] Can we forget LISP, please? >=20 > Hi Dino, >=20 > El 02/03/2007, a las 2:06, Dino Farinacci escribi=F3: >=20 > >> Aren't you dismissing an obvious third solution, i.e. the use of=20 > >> cryptographically bound identities as IDs? It seems to me=20 > that LISP=20 > >> would work rather well with CGAs as in SHIM6? > > > > Okay, I need a precise explanation here for me to get any=20 > value out of=20 > > this email. Saying "LISP would work well with CGAs as in=20 > SHIM6" could=20 > > mean so many things. So please enlighten me. > > >=20 >=20 > Darrel identified two main security aspects that he described as: >=20 > > The first, as you mention above, is the ability to 'fake'=20 > ICMP request=20 > > packets. It is important to note that ICMP isn't the problem, LISP=20 > > could have picked a new IP protocol number and packet, used UDP, or=20 > > any number of things, but the problem would remain. When a new=20 > > mapping request packet arrives at the ETR, the ETR cannot=20 > just process=20 > > this packet without some way to validate that this packet came from=20 > > the source in the source address field. Rate limiting=20 > these packets=20 > > is not a solution due to the inability to classify good from bad by=20 > > just looking at the initial packet. >=20 > > There are two ways to solve this problem today* (maybe=20 > more...?), one=20 > > is a multi-packet exchange that uses nonce values and return=20 > > routability to verify the source. TCP syn-cookies is an example of=20 > > this type of approach. The second is some sort of proof of=20 > identity=20 > > using symmetrical keying. Both of these approaches can be=20 > implemented=20 > > in the dataplane, which will be a requirement to avoid the DoS. > > > > > > The second major challenge that I see in LISP is the case where a=20 > > source spoofs the ID of a third party and sends a packet from a=20 > > reachable/valid locator. The ETR needs a mechanism to validate the=20 > > ITR/Locator mapping. > > (Today this is done with return routability, which makes it very=20 > > difficult to fake establishment of TCP connections without being a=20 > > MITM attack, or L2 spoofing). Some sort of cert based=20 > ID/Loc mapping=20 > > database needs to exist for the ETR to be able to use to=20 > verify that=20 > > the source ID/Loc is valid. > > > > There may be many other security issues out there, but if=20 > we can solve=20 > > these two and not break LISP, IMHO we'll have a good foundation to=20 > > work on. >=20 > As i see it, both are about validating the source of the=20 > packet, wwhether the source locator or the source identifier=20 > In order to validate that the source address contained in the=20 > source address field of the packet, you could use CGAs as the=20 > source address. > since CGA are derived from a public key, containing some form=20 > of signature inside the packet itself generated with the=20 > associated private key would prove that the actual owner of=20 > the source address did generated the packet. >=20 > i can go further into details if you are itnerested, but this=20 > is the main idea i think >=20 > Regards, marcelo >=20 >=20 > hope this helps >=20 > >>> The second major challenge that I see in LISP is the case where a=20 > >>> source spoofs the ID of a third party and sends a packet from a=20 > >>> reachable/valid locator. The ETR needs a mechanism to=20 > validate the=20 > >>> ITR/Locator mapping. > >> > >> This is trivial with CGAs. > > > > Again, explain. > > > > Dino > > > > _______________________________________________ > > RAM mailing list > > RAM@iab.org > > https://www1.ietf.org/mailman/listinfo/ram > > >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 10:30: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 1HN9ga-00059o-GS; Fri, 02 Mar 2007 10:28:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN9gZ-00059e-KJ for ram@iab.org; Fri, 02 Mar 2007 10:28:43 -0500 Received: from mtagate5.uk.ibm.com ([195.212.29.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN9gX-000481-45 for ram@iab.org; Fri, 02 Mar 2007 10:28:43 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate5.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l22FSe9W209186 for ; Fri, 2 Mar 2007 15:28:40 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l22FScN81499314 for ; Fri, 2 Mar 2007 15:28:40 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l22FSblU009209 for ; Fri, 2 Mar 2007 15:28:37 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l22FSbuZ009193; Fri, 2 Mar 2007 15:28:37 GMT Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA303102; Fri, 2 Mar 2007 16:28:35 +0100 Message-ID: <45E842A1.3030009@zurich.ibm.com> Date: Fri, 02 Mar 2007 16:28:33 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] Terminology: ID/Locator split References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> <45E7E758.9030704@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 We agree completely. Brian On 2007-03-02 15:01, RJ Atkinson wrote: > > On 2 Mar 2007, at 03:59, Brian E Carpenter wrote: >> I've already expressed my concern that the word "split" >> is wrong in itself for many of the solutions being >> considered. > > Agreed. > >> What we have in reality today are context- >> dependent locators, which in some contexts are used as >> identifiers for transport, security, applications or network >> management. > > Agreed. > >> The question really is whether we embrace >> this architecturally (which shim6 and lisp both do) >> or whether we try to change it by abolishing the >> context dependency (which is what a true split would >> do). > > I don't think LISP does. As near as I can tell, > LISP separates the routing space into 2 distinct > pieces -- so to me LISP looks like a "Multiple Locator" > solution rather than a "Identifier/Locator Split". > > In particular, with LISP the transport session state > still includes location information (albeit not all > of the location information), which seems to disqualify > it from the "ID/Locator Split" category. > > As I've said in other notes, I don't think that the solution > necessarily requires a strict "ID/Locator Split". I do > think that clear conversation is assisted by being crisp > and clear in how one describes various proposals' architectural > approach. > > Thanks, > > Ran > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 10:57: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 1HNA6T-000140-EV; Fri, 02 Mar 2007 10:55:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN1No-0001sp-SK; Fri, 02 Mar 2007 01:36:48 -0500 Received: from neo-u2.ops-netman.net ([2001:408:1009:1:2d0:a8ff:fe00:4bc4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN1Nm-0007O7-Vg; Fri, 02 Mar 2007 01:36:48 -0500 Received: from [IPv6?2001?408?1009?2?211?24ff?fea9?7105] (en1.russian-fingers.as701.net [IPv6:2001:408:1009:2:211:24ff:fea9:7105]) by neo-u2.ops-netman.net (Postfix) with ESMTP id 9094613B5; Fri, 2 Mar 2007 06:36:33 +0000 (GMT) In-Reply-To: <816DD9299957E547B5D758D7F977D6DC0179E96C@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC0179E96C@tayexc14.americas.cpqcorp.net> 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: Chris Morrow Subject: Re: [arch-d] Re: [RAM] IRTF RRG: call for participation Date: Fri, 2 Mar 2007 01:36:31 -0500 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-Mailman-Approved-At: Fri, 02 Mar 2007 10:55:28 -0500 Cc: Tony Li , architecture-discuss@ietf.org, ram@ietf.org, Lixia Zhang 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 Mar 2, 2007, at 12:20 AM, Bound, Jim wrote: > but it is scheduled on a saturday :--). > but it's important... > /jim > >> -----Original Message----- >> From: Lixia Zhang [mailto:lixia@CS.UCLA.EDU] >> Sent: Tuesday, February 27, 2007 11:14 AM >> To: Romascanu, Dan ((Dan)) >> Cc: Tony Li; ram@ietf.org; architecture-discuss@ietf.org >> Subject: [arch-d] Re: [RAM] IRTF RRG: call for participation >> >> >> On Feb 27, 2007, at 3:15 AM, Romascanu, Dan ((Dan)) wrote: >> >>> Is this meeting open to everybody, open to the IETF meeting >> attendees, >>> not open? >>> >>> Dan >> >> Yes this RRG meeting is open to everyone. We need the >> community's joint effort to develop a good architectural solution. >> We would like to encourage people to register for IETF as >> IETF resources are being used to provide the room, projector, >> network access, etc. for this meeting. However for those who >> do not plan to attend IETF otherwise, it seems unpractical to >> require them to register for IETF. >> >>>> -----Original Message----- >>>> From: Tony Li [mailto:tli@cisco.com] >>>> Sent: Tuesday, February 27, 2007 12:01 AM >>>> To: architecture-discuss@ietf.org; ram@ietf.org >>>> Cc: Lixia Zhang >>>> Subject: [RAM] IRTF RRG: call for participation >>>> >>>> >>>> Hi, >>>> >>>> The Routing Research Group of the IRTF will be holding a one-day >>>> seminar in Prague on March 17th to discuss the >> architectural issues >>>> confronting the Internet. This meeting will be held in >> conjunction >>>> with, and just prior to, the upcoming IETF meeting. >>>> >>>> We would like to invite researchers to participate in this seminar >>>> and in the ongoing activities of the RRG. We are calling for >>>> contributions and talks on architectural problem analysis and >>>> proposed alternative routing and addressing architectures for the >>>> Internet. >>>> >>>> Please contact the RRG co-chairs, Lixia Zhang and myself, >> if you are >>>> interested in giving a presentation. Currently scheduled >> talks can >>>> be found at >> http://www1.tools.ietf.org/group/irtf/trac/wiki/RRG. If >>>> you are making a presentation, we do ask that your >> material (papers, >>>> slides, etc.) be made available via the Internet prior to the >>>> seminar. >>>> >>>> Regards, >>>> Lixia & Tony >>>> >>>> _______________________________________________ >>>> RAM mailing list >>>> RAM@iab.org >>>> https://www1.ietf.org/mailman/listinfo/ram >>>> >> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss >> > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 10:57: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 1HNA6U-00016Z-0U; Fri, 02 Mar 2007 10:55:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN8wx-0004JX-31; Fri, 02 Mar 2007 09:41:35 -0500 Received: from s-utl02-dcpop.stsn.net ([72.255.0.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HN8wu-0005qT-VG; Fri, 02 Mar 2007 09:41:34 -0500 Received: from s-utl02-dcpop.stsn.net ([127.0.0.1]) by s-utl02-dcpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007030209411918710 ; Fri, 02 Mar 2007 09:41:19 -0500 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: -0.298,BAYES_00: -1.665, SARE_SUB_RAND_LETTRS4: 0.903 X-Spam-Level: Received: from [127.0.0.1] ([10.24.135.92]) by s-utl02-dcpop.stsn.net; Fri, 2 Mar 2007 09:41:19 -0500 Message-ID: <45E8377D.3010800@isi.edu> Date: Fri, 02 Mar 2007 06:41:01 -0800 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Marshall Eubanks Subject: Re: [arch-d] Re: [RAM] IRTF RRG: call for participation References: <816DD9299957E547B5D758D7F977D6DC0179E96C@tayexc14.americas.cpqcorp.net> <45E83378.9040709@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Fri, 02 Mar 2007 10:55:28 -0500 Cc: Tony Li , ram@ietf.org, Lixia Zhang , architecture-discuss@ietf.org, "Bound, Jim" , Chris Morrow 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="===============1860726157==" Errors-To: ram-bounces@iab.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1860726157== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCA610783B6592C2BB5B4515A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCA610783B6592C2BB5B4515A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Marshall Eubanks wrote: =2E.. >> Announcing this late and not giving it 'real' slots during the meeting= >> (couldn't Friday have been cleared?) isn't the best way to achieve tha= t >> goal, IMO. >=20 > Friday already has MBONE Deployment and the Routing Area Working Group > WG on top of each other; > please do not add a third. FWIW, I was suggesting clearing it, not adding to it. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigCA610783B6592C2BB5B4515A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF6Dd9E5f5cImnZrsRAhJ4AKCY/sP8773QVSPt/77DCxlbefTu0QCgqejd qbCqzgxQoiqTAtX3Zue3M5w= =yAL1 -----END PGP SIGNATURE----- --------------enigCA610783B6592C2BB5B4515A-- --===============1860726157== 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 --===============1860726157==-- From ram-bounces@iab.org Fri Mar 02 10:57: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 1HNA6T-000140-EV; Fri, 02 Mar 2007 10:55:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN1No-0001sp-SK; Fri, 02 Mar 2007 01:36:48 -0500 Received: from neo-u2.ops-netman.net ([2001:408:1009:1:2d0:a8ff:fe00:4bc4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN1Nm-0007O7-Vg; Fri, 02 Mar 2007 01:36:48 -0500 Received: from [IPv6?2001?408?1009?2?211?24ff?fea9?7105] (en1.russian-fingers.as701.net [IPv6:2001:408:1009:2:211:24ff:fea9:7105]) by neo-u2.ops-netman.net (Postfix) with ESMTP id 9094613B5; Fri, 2 Mar 2007 06:36:33 +0000 (GMT) In-Reply-To: <816DD9299957E547B5D758D7F977D6DC0179E96C@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC0179E96C@tayexc14.americas.cpqcorp.net> 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: Chris Morrow Subject: Re: [arch-d] Re: [RAM] IRTF RRG: call for participation Date: Fri, 2 Mar 2007 01:36:31 -0500 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-Mailman-Approved-At: Fri, 02 Mar 2007 10:55:28 -0500 Cc: Tony Li , architecture-discuss@ietf.org, ram@ietf.org, Lixia Zhang 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 Mar 2, 2007, at 12:20 AM, Bound, Jim wrote: > but it is scheduled on a saturday :--). > but it's important... > /jim > >> -----Original Message----- >> From: Lixia Zhang [mailto:lixia@CS.UCLA.EDU] >> Sent: Tuesday, February 27, 2007 11:14 AM >> To: Romascanu, Dan ((Dan)) >> Cc: Tony Li; ram@ietf.org; architecture-discuss@ietf.org >> Subject: [arch-d] Re: [RAM] IRTF RRG: call for participation >> >> >> On Feb 27, 2007, at 3:15 AM, Romascanu, Dan ((Dan)) wrote: >> >>> Is this meeting open to everybody, open to the IETF meeting >> attendees, >>> not open? >>> >>> Dan >> >> Yes this RRG meeting is open to everyone. We need the >> community's joint effort to develop a good architectural solution. >> We would like to encourage people to register for IETF as >> IETF resources are being used to provide the room, projector, >> network access, etc. for this meeting. However for those who >> do not plan to attend IETF otherwise, it seems unpractical to >> require them to register for IETF. >> >>>> -----Original Message----- >>>> From: Tony Li [mailto:tli@cisco.com] >>>> Sent: Tuesday, February 27, 2007 12:01 AM >>>> To: architecture-discuss@ietf.org; ram@ietf.org >>>> Cc: Lixia Zhang >>>> Subject: [RAM] IRTF RRG: call for participation >>>> >>>> >>>> Hi, >>>> >>>> The Routing Research Group of the IRTF will be holding a one-day >>>> seminar in Prague on March 17th to discuss the >> architectural issues >>>> confronting the Internet. This meeting will be held in >> conjunction >>>> with, and just prior to, the upcoming IETF meeting. >>>> >>>> We would like to invite researchers to participate in this seminar >>>> and in the ongoing activities of the RRG. We are calling for >>>> contributions and talks on architectural problem analysis and >>>> proposed alternative routing and addressing architectures for the >>>> Internet. >>>> >>>> Please contact the RRG co-chairs, Lixia Zhang and myself, >> if you are >>>> interested in giving a presentation. Currently scheduled >> talks can >>>> be found at >> http://www1.tools.ietf.org/group/irtf/trac/wiki/RRG. If >>>> you are making a presentation, we do ask that your >> material (papers, >>>> slides, etc.) be made available via the Internet prior to the >>>> seminar. >>>> >>>> Regards, >>>> Lixia & Tony >>>> >>>> _______________________________________________ >>>> RAM mailing list >>>> RAM@iab.org >>>> https://www1.ietf.org/mailman/listinfo/ram >>>> >> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss >> > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 10:57: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 1HNA6U-00016Z-0U; Fri, 02 Mar 2007 10:55:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN8wx-0004JX-31; Fri, 02 Mar 2007 09:41:35 -0500 Received: from s-utl02-dcpop.stsn.net ([72.255.0.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HN8wu-0005qT-VG; Fri, 02 Mar 2007 09:41:34 -0500 Received: from s-utl02-dcpop.stsn.net ([127.0.0.1]) by s-utl02-dcpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007030209411918710 ; Fri, 02 Mar 2007 09:41:19 -0500 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: -0.298,BAYES_00: -1.665, SARE_SUB_RAND_LETTRS4: 0.903 X-Spam-Level: Received: from [127.0.0.1] ([10.24.135.92]) by s-utl02-dcpop.stsn.net; Fri, 2 Mar 2007 09:41:19 -0500 Message-ID: <45E8377D.3010800@isi.edu> Date: Fri, 02 Mar 2007 06:41:01 -0800 From: Joe Touch User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Marshall Eubanks Subject: Re: [arch-d] Re: [RAM] IRTF RRG: call for participation References: <816DD9299957E547B5D758D7F977D6DC0179E96C@tayexc14.americas.cpqcorp.net> <45E83378.9040709@isi.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.2.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Fri, 02 Mar 2007 10:55:28 -0500 Cc: Tony Li , ram@ietf.org, Lixia Zhang , architecture-discuss@ietf.org, "Bound, Jim" , Chris Morrow 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="===============1860726157==" Errors-To: ram-bounces@iab.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1860726157== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCA610783B6592C2BB5B4515A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCA610783B6592C2BB5B4515A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Marshall Eubanks wrote: =2E.. >> Announcing this late and not giving it 'real' slots during the meeting= >> (couldn't Friday have been cleared?) isn't the best way to achieve tha= t >> goal, IMO. >=20 > Friday already has MBONE Deployment and the Routing Area Working Group > WG on top of each other; > please do not add a third. FWIW, I was suggesting clearing it, not adding to it. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enigCA610783B6592C2BB5B4515A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF6Dd9E5f5cImnZrsRAhJ4AKCY/sP8773QVSPt/77DCxlbefTu0QCgqejd qbCqzgxQoiqTAtX3Zue3M5w= =yAL1 -----END PGP SIGNATURE----- --------------enigCA610783B6592C2BB5B4515A-- --===============1860726157== 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 --===============1860726157==-- From ram-bounces@iab.org Fri Mar 02 11: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 1HNAaB-0004dt-Nx; Fri, 02 Mar 2007 11:26:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNAaA-0004dU-Gk for ram@iab.org; Fri, 02 Mar 2007 11:26:10 -0500 Received: from imo-m23.mx.aol.com ([64.12.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNAa8-000666-5s for ram@iab.org; Fri, 02 Mar 2007 11:26:10 -0500 Received: from HeinerHummel@aol.com by imo-m23.mx.aol.com (mail_out_v38_r7.6.) id r.d14.4fbc542 (48600); Fri, 2 Mar 2007 11:25:38 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Fri, 2 Mar 2007 11:25:37 EST Subject: Re: [RAM] Terminology: ID/Locator split To: brc@zurich.ibm.com, rja@extremenetworks.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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="===============1480573869==" Errors-To: ram-bounces@iab.org --===============1480573869== Content-Type: multipart/alternative; boundary="-----------------------------1172852737" -------------------------------1172852737 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 "Addressing can follow topology or topology can follow addressing. Choose=20 one." Jakov's law. We had such discussion before. Maybe we should get back to it =20 again? =20 Heiner =20 In einer eMail vom 02.03.2007 16:29:57 Westeurop=E4ische Normalzeit schreibt= =20 brc@zurich.ibm.com: We agree completely. Brian On 2007-03-02 15:01, RJ Atkinson wrote: >=20 > On 2 Mar 2007, at 03:59, Brian E Carpenter wrote: >> I've already expressed my concern that the word "split" >> is wrong in itself for many of the solutions being >> considered. >=20 > Agreed. >=20 >> What we have in reality today are context- >> dependent locators, which in some contexts are used as >> identifiers for transport, security, applications or network >> management. >=20 > Agreed. >=20 >> The question really is whether we embrace >> this architecturally (which shim6 and lisp both do) >> or whether we try to change it by abolishing the >> context dependency (which is what a true split would >> do). > =20 > I don't think LISP does. As near as I can tell, > LISP separates the routing space into 2 distinct > pieces -- so to me LISP looks like a "Multiple Locator" > solution rather than a "Identifier/Locator Split". >=20 > In particular, with LISP the transport session state > still includes location information (albeit not all > of the location information), which seems to disqualify > it from the "ID/Locator Split" category. >=20 > As I've said in other notes, I don't think that the solution > necessarily requires a strict "ID/Locator Split". I do > think that clear conversation is assisted by being crisp > and clear in how one describes various proposals' architectural > approach. > =20 > Thanks, >=20 > Ran > =20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram =20 -------------------------------1172852737 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
"Addressing can follow topology or topology can follow addressing.= =20 Choose one."
Jakov's law. We had such discussion before. Maybe we should get back to= it=20 again?
 
Heiner
 
In einer eMail vom 02.03.2007 16:29:57 Westeurop=E4ische Normalzeit sch= reibt=20 brc@zurich.ibm.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>We agree=20 completely.

     Brian

On 2007-03-02 15:01, R= J=20 Atkinson wrote:
>
> On  2 Mar 2007, at 03:59, Brian E=20 Carpenter wrote:
>> I've already expressed my concern that the wo= rd=20 "split"
>> is wrong in itself for many of the solutions=20 being
>> considered.
>
> Agreed.
>
>>= ;=20 What we have in reality today are context-
>> dependent locators,= =20 which in some contexts are used as
>> identifiers for transport,=20 security, applications or network
>> management.
>
>= =20 Agreed.
>
>> The question really is whether we=20 embrace
>> this architecturally (which shim6 and lisp both=20 do)
>> or whether we try to change it by abolishing the
>&g= t;=20 context dependency (which is what a true split would
>> do).
&= gt;=20
> I don't think LISP does.  As near as I can tell,
> LIS= P=20 separates the routing space into 2 distinct
> pieces -- so to me LIS= P=20 looks like a "Multiple Locator"
> solution rather than a=20 "Identifier/Locator Split".
>
> In particular, with LISP the=20 transport session state
> still includes location information (albei= t=20 not all
> of the location information), which seems to=20 disqualify
> it from the "ID/Locator Split" category.
>
&g= t;=20 As I've said in other notes, I don't think that the solution
>=20 necessarily requires a strict "ID/Locator Split".  I do
> think= =20 that clear conversation is assisted by being crisp
> and clear in ho= w=20 one describes various proposals' architectural
> approach.
>=20
> Thanks,
>
> Ran
>=20

_______________________________________________
RAM mailing=20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 
 -------------------------------1172852737-- --===============1480573869== 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 --===============1480573869==-- From ram-bounces@iab.org Fri Mar 02 12:07: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 1HNBBc-0000gQ-Ci; Fri, 02 Mar 2007 12:04:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNBBa-0000YQ-GX for ram@iab.org; Fri, 02 Mar 2007 12:04:50 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNBBY-0002Qr-77 for ram@iab.org; Fri, 02 Mar 2007 12:04:50 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2007 09:04:47 -0800 X-IronPort-AV: i="4.14,243,1170662400"; d="scan'208"; a="44572873:sNHT43414443" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l22H4l1r024074; Fri, 2 Mar 2007 09:04:47 -0800 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 l22H4cnV027819; Fri, 2 Mar 2007 09:04:42 -0800 (PST) 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); Fri, 2 Mar 2007 09:04:42 -0800 Received: from [192.168.0.4] ([10.21.97.82]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 09:04:41 -0800 In-Reply-To: <0B6CD3B7-0B90-4E9F-AEC0-55E417865F2E@nomadiclab.com> References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> <0B6CD3B7-0B90-4E9F-AEC0-55E417865F2E@nomadiclab.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: Dino Farinacci Subject: Re: [RAM] PASH: Another SHIM6 proxying draft, in addition to pshim6 Date: Fri, 2 Mar 2007 09:04:45 -0800 To: Pekka Nikander X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Mar 2007 17:04:41.0894 (UTC) FILETIME=[DE898460:01C75CEC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=536; t=1172855087; x=1173719087; c=relaxed/simple; s=sjdkim5002; 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]=20PASH=3A=20Another=20SHIM6=20proxying=20draft, =20in=20addition=20to=20pshim6 |Sender:=20; bh=WWxV3snFj7FNzKYLk+4emiTwCaDjWBwa8aMUgBkW17M=; b=hBeEPfo8YWgn+zDQiHEmtDOS7VhzgVmnj5SyGxx7INvmMPG7155gSpkxprF5PzhhOfJUTSbv SOXnRWIHnoqO6sHQL9kBIBM7o56K3ocm1Uk66W9t0k4b+2XN3GavBysX; Authentication-Results: sj-dkim-5; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 > It is not as detailed as PSHIM6; instead it tries to show that it > is indeed possible to use SHIM6 (and HIP) in a LISP-like way. Pekka, I'm going through our IDs, but can you provide me a quick, but more specific reply to the above? What is a "LISP-like way" that SHIM6 and HIP do not have right now? It makes it sound that SHIM6 and HIP do not have something that LISP does and that you can change them to have it. And what you want them to have seems of value to you, so can you identify it? Thanks, Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 12:58: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 1HNC0Z-0003Y5-07; Fri, 02 Mar 2007 12:57:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNC0Y-0003Xz-Aw for ram@iab.org; Fri, 02 Mar 2007 12:57:30 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNC0R-0002rj-Sm for ram@iab.org; Fri, 02 Mar 2007 12:57:30 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BA5EA212D4D; Fri, 2 Mar 2007 19:57:22 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 41C97212D48; Fri, 2 Mar 2007 19:57:22 +0200 (EET) In-Reply-To: <5CBBBB37-FF7F-4247-BE8B-18E461187F93@extremenetworks.com> References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> <90D707E7-1292-4A9C-A424-28229E5EA77C@nomadiclab.com> <5CBBBB37-FF7F-4247-BE8B-18E461187F93@extremenetworks.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: Pekka Nikander Subject: Re: [RAM] Terminology: ID/Locator split Date: Fri, 2 Mar 2007 17:27:38 +0200 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 >>> A. The separation may be implemented above the current >>> transport >>> layer, mainly TCP and UDP. >>> >>> B. The separation may be implemented at or below the >>> transport >>> (i.e. below the socket API) but above the routing part >>> of the >>> IP layer. >>> >>> C. The separation may be implemented below the host-part >>> of the >>> IP layer. >> >> Of these, the middle one (B) is closest to the traditional use of >> the term [Chiappa]. > > I think the term originally comes from JNC. I first heard it from > him in person. To be honest, I don't think that either A or C > strictly comply with his definition. I agree. I think this all boils down to the difference between "separation" vs. "split", as Brian pointed out. I plead guilty to carelessness in my use of terms. > It would actually HELP the discussion -- and likely help some of > the non-ID/Locator Split proposals -- if we did not mis-use JNC's > original (clearer) terminology, IMHO. I agree. The question remains how should we define id/loc *separation* [Re: Brian's message and your reply to that.] >> And there, only some of the proposed solutions, like HIP and >> SHIM6, really match with the original idea. At least those that >> do match seem to comply with your definition, but perhaps also >> others. > > I would agree that HIP complies. I am doubtful about SHIM6, since > one has a single namespace that is overloaded for both routing and > identity. SHIM6 seems to be "NAT inside the host" -- again that's > not necessarily bad, just trying to be a clear description of the > proposal. Oh, I'd agree with you if I were to stuck to the current SHIM6 specs. But, perhaps unfortunately, I tend to think about SHIM6 in broader terms than the WG appears to. Architecturally, I think it has potential to much more than what the WG charter or the current protocols really make possible. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 13:45:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNCj3-0002Ow-Ti; Fri, 02 Mar 2007 13:43:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNCj2-0002MT-Vu for ram@iab.org; Fri, 02 Mar 2007 13:43:28 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNCj0-0000up-IP for ram@iab.org; Fri, 02 Mar 2007 13:43:28 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 45063212D4D; Fri, 2 Mar 2007 20:43:21 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BFD19212D48; Fri, 2 Mar 2007 20:43:20 +0200 (EET) In-Reply-To: References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> <0B6CD3B7-0B90-4E9F-AEC0-55E417865F2E@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9CB8C7D2-4D3E-4340-BC33-C616D46B18C5@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] PASH: Another SHIM6 proxying draft, in addition to pshim6 Date: Fri, 2 Mar 2007 20:43:17 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 >> It is not as detailed as PSHIM6; instead it tries to show that it >> is indeed possible to use SHIM6 (and HIP) in a LISP-like way. > > Pekka, I'm going through our IDs, but can you provide me a quick, > but more specific reply to the above? What is a "LISP-like way" > that SHIM6 and HIP do not have right now? In a word: deployment. Your LISP 1, 1.5, 2, 3 construction is nice, as I already wrote. I had been thinking about HIP proxying for years, and about deployment along the same lines as you do in LISP, but never managed to put it down before now. Thanks for forcing me to do it. :-) > It makes it sound that SHIM6 and HIP do not have something that > LISP does and that you can change them to have it. And what you > want them to have seems of value to you, so can you identify it? Again: deployment. I think the LISP deployment path idea is really nice, for a starter. Sorry for being blunt, but other than that I consider LISP very under- developed. As I have stated, once you add security and multi-homing/ TE support you probably get something very much like SHIM6, at least for the IPv6 EID case. (You can still run it over IPv4 core.) As far as I can see, security for the IPv4 EID case is a more-or-less unsolved problem at this point; I don't think the community would even agree on requirements. So, if I was forced to pick my plate from the currently discussed smorgasbord, I would pick the following: 1. A deployment path starting from LISP-like in-the-network approaches, gradually going to host-based ones, at least for mobile hosts. 2. SHIM6-like mapping set-up and maintenance protocols. 3. SHIM6-like security model with a LISP1.5-like deployment model, with IPv6 EID support only and with a separate routing infrastructure for locators (IPv4) and identifiers (IPv6). 4. Ability for multiple tunnelling formats (negotiated), including SHIM6 tags and IPsec ESP. 5. Forward compatibility with HIP, for LISP 2 and 3 like deployments, with ORCHIDs instead of CGAs. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 17:18: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 1HNG3Q-0000EO-Jn; Fri, 02 Mar 2007 17:16:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNEoQ-0000N9-Da for ram@iab.org; Fri, 02 Mar 2007 15:57:11 -0500 Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNEnt-0002cd-Ci for ram@iab.org; Fri, 02 Mar 2007 15:57:10 -0500 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id AB5F67E4C for ; Fri, 2 Mar 2007 12:56:20 -0800 (PST) Received: from JMHLap3.joelhalpern.com (unknown [63.88.112.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 0117A7DFA for ; Fri, 2 Mar 2007 12:56:18 -0800 (PST) Message-Id: <7.0.1.0.0.20070302155218.039288d0@joelhalpern.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 02 Mar 2007 15:56:16 -0500 To: ram@iab.org From: "Joel M. Halpern" Subject: Re: [RAM] Terminology: ID/Locator split In-Reply-To: <45E7E758.9030704@zurich.ibm.com> References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> <45E7E758.9030704@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Reading the various notes, and trying to state what the distinction I have understood is, I end up with: One value is globally routable. The other value is globally unique and is used by the host stack to identify itself / its communicating partner. It is not globally routable. Whether that is a "split" a "separation" or something else probably depends upon how it is done. It certainly gets harder to explain when for good (mostly evolution) reasons we use the same structure of bits to fulfill both functions. It gets really confused when as further transition we actually use globally routable bit strings for the identifier. At that point, I do have to agree that we don't have much of a "split" any more. (Of course, the agreement of an approach with a specific word is NOT the condition for it being or not being useful to consider.) Yours, Joel At 03:59 AM 3/2/2007, Brian E Carpenter wrote: >I've already expressed my concern that the word "split" >is wrong in itself for many of the solutions being >considered. What we have in reality today are context- >dependent locators, which in some contexts are used as >identifiers for transport, security, applications or network >management. The question really is whether we embrace >this architecturally (which shim6 and lisp both do) >or whether we try to change it by abolishing the >context dependency (which is what a true split would >do). > > Brian > >On 2007-03-01 19:39, RJ Atkinson wrote: >> In some off-list conversations, it seems that there >>are varying definitions for the phrase "ID-Locator split". >>I suspect the variance in definitions for that phrase is >>causing some confusion in discussions on this list. >> To my mind, when one talks about an "ID/Locator split", >>an essential property is that one has both: >>1) a "Locator" which is ONLY used for packet forwarding >> and is NEVER visible above the network-layer >> (e.g. no name ever used for network-layer packet forwarding >> is ever visible to TCP) >>&& >>2) an "Identifier" that is used by the transport-layer >> (e.g. in TCP session state, such as TCP pseudo-header checksum), >> might be used above the transport-layer, and >> is NEVER used for network-layer packet forwarding. >> >>If other folks have CRISP and CLEAR alternative definitions >>for "ID-Locator split", then it might be interesting to know >>precisely what those alternative definitions are... >>Ran >> >>_______________________________________________ >>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 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 17:18: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 1HNG55-00012D-K5; Fri, 02 Mar 2007 17:18:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNFKs-0000Mn-LU for ram@iab.org; Fri, 02 Mar 2007 16:30:42 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNF9A-00059H-CU for ram@iab.org; Fri, 02 Mar 2007 16:18:59 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2007 13:18:37 -0800 X-IronPort-AV: i="4.14,244,1170662400"; d="scan'208"; a="396082703:sNHT152443354" 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 l22LIZWU009162; Fri, 2 Mar 2007 13:18:35 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l22LI4HK011230; Fri, 2 Mar 2007 13:18:24 -0800 (PST) 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); Fri, 2 Mar 2007 13:18:22 -0800 Received: from [192.168.0.4] ([10.21.97.82]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 13:18:21 -0800 In-Reply-To: <9CB8C7D2-4D3E-4340-BC33-C616D46B18C5@nomadiclab.com> References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> <0B6CD3B7-0B90-4E9F-AEC0-55E417865F2E@nomadiclab.com> <9CB8C7D2-4D3E-4340-BC33-C616D46B18C5@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6BB8C91A-6E71-44DD-9A4A-3AF4F11EB803@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] PASH: Another SHIM6 proxying draft, in addition to pshim6 Date: Fri, 2 Mar 2007 13:18:25 -0800 To: Pekka Nikander X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Mar 2007 21:18:21.0993 (UTC) FILETIME=[4E6C5190:01C75D10] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1879; t=1172870315; x=1173734315; 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]=20PASH=3A=20Another=20SHIM6=20proxying=20draft, =20in=20addition=20to=20pshim6 |Sender:=20; bh=uJRnllmkMK0Sc663wtWd4pekc2KncDnsirrMxKK+tKg=; b=HfFGZgg18gk78n1NN5QxdcqUiWnYNSGv1U7WX5bRnXWuamZQ5DtUm5Rf9HihMVu9kr53g5op Im3q1pQrvXzzCFQFLqyYMQsSqL218l2cl8TgNFHXN/0Ox1vMMxG7DTwy; 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: 8b431ad66d60be2d47c7bfeb879db82c 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 > Sorry for being blunt, but other than that I consider LISP very > under-developed. Sorry, but that was intended, a feature and not a bug. > As I have stated, once you add security and multi-homing/TE > support you probably get something very much like SHIM6, at least > for the IPv6 EID case. I don't think so. Some things are meant to be left alone. Multi- homing and TE are already there so I don't know what you mean. And you can do a lot with less rather than more. Let's have deployment tell us what we really need. It's too early to say what we *really* need. Everything needs security, but if you really take a look at the Internet under the covers, very little of it (at layer 3) has any security. Now why is that? If it was such a serious problem, don't you think it would have been deployed by now? > 1. A deployment path starting from LISP-like in-the-network > approaches, gradually going to host-based ones, at least for mobile > hosts. Okay, makes sense. > 2. SHIM6-like mapping set-up and maintenance protocols. Sorry, way too complicated for my tastes. And I'm not alone here. > 3. SHIM6-like security model with a LISP1.5-like deployment model, > with IPv6 EID support only and with a separate routing > infrastructure for locators (IPv4) and identifiers (IPv6). Tell me specifically what SHIM6-like security model you are talking about. > 4. Ability for multiple tunnelling formats (negotiated), including > SHIM6 tags and IPsec ESP. Why do we need this? How about just ESP (or maybe just AH). > 5. Forward compatibility with HIP, for LISP 2 and 3 like > deployments, with ORCHIDs instead of CGAs. Right, pretty grandiose IMO. It sounds like you are compromising and taking a little from everywhere. In my experience, this is a recipe for disaster. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 17:26: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 1HNGD3-0005m8-7N; Fri, 02 Mar 2007 17:26:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNGD1-0005kl-VN for ram@iab.org; Fri, 02 Mar 2007 17:26:39 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNGCw-0003Rb-5Z for ram@iab.org; Fri, 02 Mar 2007 17:26:39 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2007 14:26:35 -0800 X-IronPort-AV: i="4.14,244,1170662400"; d="scan'208"; a="396116876:sNHT44464430" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l22MQXQs015674; Fri, 2 Mar 2007 14:26:33 -0800 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 l22MQXho008452; Fri, 2 Mar 2007 14:26:33 -0800 (PST) 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); Fri, 2 Mar 2007 14:26:33 -0800 Received: from [192.168.0.4] ([10.21.97.82]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 14:26:32 -0800 In-Reply-To: <7.0.1.0.0.20070302155218.039288d0@joelhalpern.com> References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> <45E7E758.9030704@zurich.ibm.com> <7.0.1.0.0.20070302155218.039288d0@joelhalpern.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: Dino Farinacci Subject: Re: [RAM] Terminology: ID/Locator split Date: Fri, 2 Mar 2007 14:26:36 -0800 To: "Joel M. Halpern" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Mar 2007 22:26:32.0727 (UTC) FILETIME=[D4B0CA70:01C75D19] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=778; t=1172874393; x=1173738393; 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]=20Terminology=3A=20ID/Locator=20split |Sender:=20; bh=xOdyOVMWYs+dTWf+O/Ox0ndy4WSyWyFfhWNrb6b+yxM=; b=EHaGb8yKtOhOAiFjdKHTNo4xXdWL6BFWv6rFijYI23BVucj1pfzD09BXDB29hA2iQg6HDjRa pJ1FPv1q+icbcnKD2CppJVJzcm0nJhwbTXFvrlHKz0VhORCOrIPbuevS; 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: 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 > Whether that is a "split" a "separation" or something else probably > depends upon how it is done. > It certainly gets harder to explain when for good (mostly > evolution) reasons we use the same structure of bits to fulfill > both functions. > It gets really confused when as further transition we actually use > globally routable bit strings for the identifier. > At that point, I do have to agree that we don't have much of a > "split" any more. (Of course, the agreement of an approach with a > specific word is NOT the condition for it being or not being useful > to consider.) Would you say if IDs were from PI space and not injected into the routing system, we then have a true split? Dino P.S. Modulo site-based routing on the ID. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 17:35:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNGLP-0000xp-Av; Fri, 02 Mar 2007 17:35:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNGLN-0000xU-Jn for ram@iab.org; Fri, 02 Mar 2007 17:35:17 -0500 Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNGLH-0004tC-7Q for ram@iab.org; Fri, 02 Mar 2007 17:35:17 -0500 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id B10CA7E35 for ; Fri, 2 Mar 2007 14:35:07 -0800 (PST) Received: from JMHLap3.joelhalpern.com (unknown [63.88.112.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 2DBCD7DD0 for ; Fri, 2 Mar 2007 14:35:04 -0800 (PST) Message-Id: <7.0.1.0.0.20070302172911.03930f50@joelhalpern.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 02 Mar 2007 17:35:01 -0500 To: ram@iab.org From: "Joel M. Halpern" Subject: Re: [RAM] Terminology: ID/Locator split In-Reply-To: References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> <45E7E758.9030704@zurich.ibm.com> <7.0.1.0.0.20070302155218.039288d0@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 05:26 PM 3/2/2007, Dino Farinacci wrote: >>Whether that is a "split" a "separation" or something else probably >>depends upon how it is done. >>It certainly gets harder to explain when for good (mostly >>evolution) reasons we use the same structure of bits to fulfill >>both functions. >>It gets really confused when as further transition we actually use >>globally routable bit strings for the identifier. >>At that point, I do have to agree that we don't have much of a >>"split" any more. (Of course, the agreement of an approach with a >>specific word is NOT the condition for it being or not being useful >>to consider.) > >Would you say if IDs were from PI space and not injected into the >routing system, we then have a true split? My personal take is that the example you reference is a "true split" in that the ID. Since it (and any meaningful prefix of it) is not injected in the global routing table, it is not globally routable. I don't think that the fact that in some conceivable alternate universe the ID could have been routable makes it not an ID. Even if the alternate universe is one we have all lived in before this gets done right >Dino > >P.S. Modulo site-based routing on the ID. Yours, Joel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 02 18:00: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 1HNGjH-0002YC-Iy; Fri, 02 Mar 2007 17:59:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNGjF-0002Xj-Pm for ram@iab.org; Fri, 02 Mar 2007 17:59:57 -0500 Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNGjE-00015w-CU for ram@iab.org; Fri, 02 Mar 2007 17:59:57 -0500 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id BD38E7DDC for ; Fri, 2 Mar 2007 14:59:46 -0800 (PST) Received: from JMHLap3.joelhalpern.com (unknown [63.88.112.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 6653F7E2E for ; Fri, 2 Mar 2007 14:59:44 -0800 (PST) Message-Id: <7.0.1.0.0.20070302175824.0395e8a0@joelhalpern.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 02 Mar 2007 17:59:41 -0500 To: ram@iab.org From: "Joel M. Halpern" Subject: Re: [RAM] Terminology: ID/Locator split In-Reply-To: <7.0.1.0.0.20070302172911.03930f50@joelhalpern.com> References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> <45E7E758.9030704@zurich.ibm.com> <7.0.1.0.0.20070302155218.039288d0@joelhalpern.com> <7.0.1.0.0.20070302172911.03930f50@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 (Spenser noted that I got the words twisted around.) My point was that the fact that it could have been injected (into the global table) does NOT turn an ID into a LOC. Injecting it would turn it into a LOC. Joel At 05:35 PM 3/2/2007, Joel M. Halpern wrote: >At 05:26 PM 3/2/2007, Dino Farinacci wrote: >>>Whether that is a "split" a "separation" or something else probably >>>depends upon how it is done. >>>It certainly gets harder to explain when for good (mostly >>>evolution) reasons we use the same structure of bits to fulfill >>>both functions. >>>It gets really confused when as further transition we actually use >>>globally routable bit strings for the identifier. >>>At that point, I do have to agree that we don't have much of a >>>"split" any more. (Of course, the agreement of an approach with a >>>specific word is NOT the condition for it being or not being useful >>>to consider.) >> >>Would you say if IDs were from PI space and not injected into the >>routing system, we then have a true split? > >My personal take is that the example you reference is a "true split" >in that the ID. Since it (and any meaningful prefix of it) is not >injected in the global routing table, it is not globally >routable. I don't think that the fact that in some conceivable >alternate universe the ID could have been routable makes it not an >ID. Even if the alternate universe is one we have all lived in >before this gets done right > > >>Dino >> >>P.S. Modulo site-based routing on the ID. > >Yours, >Joel > > > > >_______________________________________________ >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 Fri Mar 02 18:11: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 1HNGtk-0006zF-TW; Fri, 02 Mar 2007 18:10:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNFHt-0007JV-4K for ram@iab.org; Fri, 02 Mar 2007 16:27:44 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HNFHk-0002LE-No for ram@iab.org; Fri, 02 Mar 2007 16:27:35 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 843D516DF29; Fri, 2 Mar 2007 22:27:17 +0100 (CET) Received: from [163.117.203.117] (unknown [163.117.203.117]) by smtp01.uc3m.es (Postfix) with ESMTP id ECF3916E1D5; Fri, 2 Mar 2007 22:27:15 +0100 (CET) In-Reply-To: <5CBBBB37-FF7F-4247-BE8B-18E461187F93@extremenetworks.com> References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> <90D707E7-1292-4A9C-A424-28229E5EA77C@nomadiclab.com> <5CBBBB37-FF7F-4247-BE8B-18E461187F93@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Terminology: ID/Locator split Date: Fri, 2 Mar 2007 22:28:55 +0100 To: RJ Atkinson X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Pekka Nikander , 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 El 02/03/2007, a las 14:57, RJ Atkinson escribi=F3: > SHIM6 seems to be "NAT inside the host" > this is not the case because shim6 restores the original addresses=20 before delivering the packet to the transport layer (which NAT does=20 not) Regards, marcelo > -- again that's not necessarily bad, just trying to be a clear > description of the proposal. > > Cheers, > > Ran > > PS: You get bonus points for citing JNC's online paper. :-) > >> --Pekka Nikander >> >> [Chiappa] Chiappa, J., "Endpoints and Endpoint Names: A Proposed >> Enhancement to the Internet Architecture", >> URL http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999. > > > _______________________________________________ > 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 Fri Mar 02 19:14: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 1HNHrC-0001P3-Cx; Fri, 02 Mar 2007 19:12:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNHqx-0000hR-Cc for ram@ietf.org; Fri, 02 Mar 2007 19:11:59 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNHqw-0003DK-2s for ram@ietf.org; Fri, 02 Mar 2007 19:11:59 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 02 Mar 2007 16:11:57 -0800 X-IronPort-AV: i="4.14,244,1170662400"; d="scan'208"; a="117544560:sNHT43281594" 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 l230Bvkh008510; Fri, 2 Mar 2007 16:11:57 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l230BuDk023785; Fri, 2 Mar 2007 16:11:57 -0800 (PST) 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); Fri, 2 Mar 2007 16:11:56 -0800 Received: from [192.168.0.4] ([10.21.82.171]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 16:11:55 -0800 In-Reply-To: <8a27c530ddfa3d61ec1fab05812d7ded@it.uc3m.es> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <60C4A248E730F249990993E3B9BD44D80322B119@xmb-sjc-218.amer.cisco.com> <6B864A95-1728-4761-8A58-5ACD3F0BE7DB@cisco.com> <8a27c530ddfa3d61ec1fab05812d7ded@it.uc3m.es> 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] Can we forget LISP, please? Date: Fri, 2 Mar 2007 16:11:59 -0800 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Mar 2007 00:11:55.0618 (UTC) FILETIME=[8D6D6420:01C75D28] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=866; t=1172880717; x=1173744717; 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]=20Can=20we=20forget=20LISP,=20please? |Sender:=20; bh=RyPfe7TGz4z5b60XCodHzooYjx+xuduoa18zdnVpjGo=; b=hI9wBcK81pej10HqehKF07gx7l2D8HnDEnl2+SDRDGPMxNigSzODB8HFDIIgkaS0mQuHu6yk aQcoTf2pjkffQFuCIeA0DbJZg/Usiwtx8lG+HbSK2a68GX1RNsP05rIe; 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: d6b246023072368de71562c0ab503126 Cc: ram@ietf.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 > As i see it, both are about validating the source of the packet, > wwhether the source locator or the source identifier > In order to validate that the source address contained in the > source address field of the packet, you could use CGAs as the > source address. > since CGA are derived from a public key, containing some form of > signature inside the packet itself generated with the associated > private key would prove that the actual owner of the source address > did generated the packet. Why not pass the public key in the message payload and have the source sign with the private key. Then it can work for any addresses you decide to use, plus IPv4. Alternately, you could send the public key in another packet, less often (only when you might want to rekey), and keep the state with the EID-RLOC mapping. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 03 01:33: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 1HNNkb-00055l-75; Sat, 03 Mar 2007 01:29:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNNkZ-00055R-3c for ram@iab.org; Sat, 03 Mar 2007 01:29:47 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNNkX-0003rb-Kf for ram@iab.org; Sat, 03 Mar 2007 01:29:47 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D8584212D4D; Sat, 3 Mar 2007 08:29:31 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 83AD0212D46; Sat, 3 Mar 2007 08:29:31 +0200 (EET) In-Reply-To: <6BB8C91A-6E71-44DD-9A4A-3AF4F11EB803@cisco.com> References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> <0B6CD3B7-0B90-4E9F-AEC0-55E417865F2E@nomadiclab.com> <9CB8C7D2-4D3E-4340-BC33-C616D46B18C5@nomadiclab.com> <6BB8C91A-6E71-44DD-9A4A-3AF4F11EB803@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: Pekka Nikander Subject: Re: [RAM] PASH: Another SHIM6 proxying draft, in addition to pshim6 Date: Sat, 3 Mar 2007 08:29:27 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP 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 >> Sorry for being blunt, but other than that I consider LISP very >> under-developed. > > Sorry, but that was intended, a feature and not a bug. Ok, but it makes comparison with something more fully developed, such as the SHIM6 *protocol*, pretty hard. That is, you get very YMMV statements due to comparing apples to oranges. Consider your own comment later: You simultaneously say that SHIM6 is too complicated and LISP is intentionally under-developed. Then you go saying that you don't believe LISP will become comparably complex with SHIM6 when fully developed while I believe so. Well, what can I say? Maybe you have some clever idea in mind that I cannot see. Or maybe you don't yet understand all the complications involved. Or maybe we just don't agree on what is needed, e.g., security wise. >> As I have stated, once you add security and multi-homing/TE >> support you probably get something very much like SHIM6, at least >> for the IPv6 EID case. > > I don't think so. Some things are meant to be left alone. Multi- > homing and TE are already there so I don't know what you mean. Well, I think I disagree. Maybe I'm wrong about multi-homing or TE, but I think my security point prevails. :-) > And you can do a lot with less rather than more. Let's have > deployment tell us what we really need. It's too early to say what > we *really* need. There I fully agree. But, my approach would be somewhat opposite to yours: instead of starting from zero and building the minimum needed, I'd start from something pretty fully developed and tested (such as SHIM6 or HIP), and remove features that are not needed for early deployment. The benefit? Forward compatibility, i.e., more-or-less technically- proven way of adding back those removed features further along the deployment path. (But I also know that technical forward compatibility does not necessarily mean forward compatibility deployment wise. It just makes such forward compatibility *potentially* much easier.) > Everything needs security, but if you really take a look at the > Internet under the covers, very little of it (at layer 3) has any > security. Now why is that? > If it was such a serious problem, don't you think it would have > been deployed by now? As I wrote, I think the community does not agree on the "requirements" here, or how bad the problem is. For me, anything that allows *new* reflection, amplification, or flooding attacks is unacceptable. The situation is bad enough already now. Any new attack vector can prove to be more effective than the old ones. But I know people who disagree with me. [Snipping my smorgasbord plate.] > Right, pretty grandiose IMO. It sounds like you are compromising > and taking a little from everywhere. In my experience, this is a > recipe for disaster. Point taken. But you forget I'm a pragmatist. I'm willing to give up any nice features that are not necessary (e.g. security wise) and turn out to be complicated to implement. Of course, I happen to believe that my choice would be quite palatable, but obviously it can turn out to be very sour or just too much to swallow, when worked out. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 03 06:01: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 1HNRvf-0003kq-OC; Sat, 03 Mar 2007 05:57:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNRv8-0003KY-G9 for ram@ietf.org; Sat, 03 Mar 2007 05:56:58 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNRuA-0001Td-6n for ram@ietf.org; Sat, 03 Mar 2007 05:55:59 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 508B310FFBA; Sat, 3 Mar 2007 11:55:57 +0100 (CET) Received: from [163.117.203.117] (unknown [163.117.203.117]) by smtp02.uc3m.es (Postfix) with ESMTP id E39CE110240; Sat, 3 Mar 2007 11:55:56 +0100 (CET) In-Reply-To: References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <60C4A248E730F249990993E3B9BD44D80322B119@xmb-sjc-218.amer.cisco.com> <6B864A95-1728-4761-8A58-5ACD3F0BE7DB@cisco.com> <8a27c530ddfa3d61ec1fab05812d7ded@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Can we forget LISP, please? Date: Sat, 3 Mar 2007 11:57:39 +0100 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ram@ietf.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 El 03/03/2007, a las 1:11, Dino Farinacci escribi=F3: >> As i see it, both are about validating the source of the packet,=20 >> wwhether the source locator or the source identifier >> In order to validate that the source address contained in the source=20= >> address field of the packet, you could use CGAs as the source=20 >> address. >> since CGA are derived from a public key, containing some form of=20 >> signature inside the packet itself generated with the associated=20 >> private key would prove that the actual owner of the source address=20= >> did generated the packet. > > Why not pass the public key in the message payload and have the source=20= > sign with the private key. Then it can work for any addresses you=20 > decide to use, plus IPv4. > the problem with this is that there is no way to bind the identifier=20 itself (which is what you want to protect) and the public/private key=20 pair. So anyone could send such a message, including its own key pair. In order to prevent this, you need to protect the binding between the=20 identifier and the key pair. One option is using certificates, but this would rely on having a=20 common trusted anchor point which for a general environment like the=20 one we are cosnidering here, would mean a global pki the other option is to have the identifier intrinsically bound to the=20 key pair, which is what CGA does, since the iid of the CGAis a hash of=20= the public key > Alternately, you could send the public key in another packet, less=20 > often (only when you might want to rekey), and keep the state with the=20= > EID-RLOC mapping. > Yes, the public key is send only in the first message when you send the=20= identifier for the first time (included in what is called the CGA=20 parameter data strucutre) and the rest of the additional locators that=20= may need to send only include the signature, (using the associated key=20= pair) regards, marcelo > Dino > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 03 06:14: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 1HNSBd-0005UG-F6; Sat, 03 Mar 2007 06:14:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNSBc-0005UA-Ia for ram@iab.org; Sat, 03 Mar 2007 06:14:00 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNSBa-0003lF-1x for ram@iab.org; Sat, 03 Mar 2007 06:14:00 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9CCBC110230; Sat, 3 Mar 2007 12:13:55 +0100 (CET) Received: from [163.117.203.117] (unknown [163.117.203.117]) by smtp02.uc3m.es (Postfix) with ESMTP id 46C3B10FF68; Sat, 3 Mar 2007 12:13:47 +0100 (CET) In-Reply-To: <6BB8C91A-6E71-44DD-9A4A-3AF4F11EB803@cisco.com> References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> <0B6CD3B7-0B90-4E9F-AEC0-55E417865F2E@nomadiclab.com> <9CB8C7D2-4D3E-4340-BC33-C616D46B18C5@nomadiclab.com> <6BB8C91A-6E71-44DD-9A4A-3AF4F11EB803@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <85c1e28248f14daf7b49a5ed8731ccd9@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] PASH: Another SHIM6 proxying draft, in addition to pshim6 Date: Sat, 3 Mar 2007 12:15:31 +0100 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Pekka Nikander , 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, El 02/03/2007, a las 22:18, Dino Farinacci escribi=F3: > >> As I have stated, once you add security and multi-homing/TE support=20= >> you probably get something very much like SHIM6, at least for the=20 >> IPv6 EID case. > > I don't think so. Some things are meant to be left alone. Multi-homing=20= > and TE are already there so I don't know what you mean. > Well, w.r.t. to multihoming, i think that one preferred feature in=20 multihoming is fault tolerance. AFAICT, in the current version of LISP,=20= the ITR is a single point of failure (see the message i sent about this=20= in http://www1.ietf.org/mail-archive/web/ram/current/msg00636.html) So, i don't think it is acceptable to have a multihoming solution which=20= goal is to provide fault tolerance and that it introduces a single=20 point of failure in a router. OTOH, i only have read LISP once, so i=20 may be missing some points, hence my previous question. I think that=20 quite some additional compelxity is needed to support to fall back to a=20= backup ITR and preserve established sessions in the cases that i have=20 described before. w.r.t. to TE, AFIU, LISP uses multiple tunneling level in order to=20 allow that some internediate router can reroute the packets. But in=20 order to do that, the intermediate router needs to discover the=20 alternative locators for the identifier contained in the packet and=20 moreover, it needs to know that the destiantion site is LISP aware=20 (which is not trivial in LISPv1, since the identifier is routable, so a=20= lisp packet can be a regular IP packet) So, in order to discover the alternative locators associated to the=20 identifier, the intermediate rotuers needs to keep track of the ICMP=20 mesages (is this the idea?). So this means that intermediate routers=20 need to store all the alternative locators for packets flowing through=20= it? What if the locator used is not the one used initially and the ICMP=20= packet didn't passed through that router initially? in this case, how=20 does the intermediate router discover the alternative locators? In=20 addition to that, you need to consider the security aspect. I mean, in=20= this case you need to provide security for the id locator binding to=20 some unspecified router in the middle. Again, i am not saying that this=20= cannot be done, just that additional complexity will be needed for sure=20= even to provide support for multihoming and TE but again, i still have a poor understanding of LISP, so i am probably=20= missing some stuff here... Regards, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 03 19:05:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNeCG-0002gn-Ql; Sat, 03 Mar 2007 19:03:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNeCF-0002gC-N1 for ram@iab.org; Sat, 03 Mar 2007 19:03:27 -0500 Received: from [207.179.9.76] (helo=smtp1.extremenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNe8D-0002Gh-QV for ram@iab.org; Sat, 03 Mar 2007 18:59:19 -0500 Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id D6CC97946 for ; Sat, 3 Mar 2007 15:59:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Subject: Re: [RAM] Terminology: ID/Locator split Date: Sat, 3 Mar 2007 18:59:04 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 > Would you say if IDs were from PI space and > not injected into the routing system, we then have a true split? No. The key distinction for "ID/Locator Split" as a term is how the object is used in a layering sense (e.g. network-layer XOR transport-layer), rather than whether something is IGP data or EGP data. If IDs are not used for network-layer packet forwarding, then one has a true split. Having a true split means (roughly) that one Identifier is never used in any network-layer routing and that transport-layer state (e.g. TCP pseudo-header checksum) does not include any sort of name used for network-layer packet forwarding. If one had an Identifier, not used for packet forwarding, but used in TCP pseudo-header calculations, I think it would still qualify as a true split even if that Identifier were used as part of an ARP/ND *cache index*. > Dino > > P.S. Modulo site-based routing on the ID. LISP is very interesting, but is NOT a true ID/Locator split. Instead, I'd say one has multiple Locator domains or multiple routing domains with LISP. And to repeat my earlier comment, I don't think that a true ID/Locator split is *required* to solve the issues that this list has been discussing. So I think it would be cleaner, clearer, and more advantagous for LISP itself if folks did not refer to LISP as an ID/Locator split approach. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 03 20:25: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 1HNfRm-0003cb-Eh; Sat, 03 Mar 2007 20:23:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNfRl-0003cV-CB for ram@iab.org; Sat, 03 Mar 2007 20:23:33 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNfRk-0005Xf-4A for ram@iab.org; Sat, 03 Mar 2007 20:23:33 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 71EA7872F0; Sat, 3 Mar 2007 20:23:30 -0500 (EST) To: ram@iab.org Subject: Re: [RAM] Terminology: ID/Locator split Message-Id: <20070304012330.71EA7872F0@mercury.lcs.mit.edu> Date: Sat, 3 Mar 2007 20:23:30 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: jnc@mercury.lcs.mit.edu 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: RJ Atkinson > The key distinction for "ID/Locator Split" as a term is how the > object is used in a layering sense (e.g. network-layer XOR > transport-layer), rather than whether something is IGP data or EGP > data. > If IDs are not used for network-layer packet forwarding, then one has > a true split. That's an interesting way to classify it, because it points out what made me so uneasy about a scheme you mentioned a while back (Jan 16 2007, Subject: "Candidate properties of some new name types", if anyone cares), where you suggested: "A Locator names a single sub-network, not an interface or node" and I was rather unhappy, because perforce this meant that the other name of the pair you suggested (an "Identifier") was therefore necessary to identify the particular interface; i.e. that "Identifier" name was used at the internetwork layer as well as the transport layer. (If the packet *cannot* be delivered by the internetworking layer *without* use of the Identifier, the Identifier is [in part] an internetworking-level name.) Oh. and while we're at it on the subject of terminology, can I convince everyone to use "internetwork layer" when they mean the internetworking layer, because "network layer" is really confusing on networks like ATM, etc which have a real network layer of their own. Just because the ISO model is crippled and doesn't have enough layers, that doesn't mean we have to swallow it lock, stock and barrel. > LISP is very interesting, but is NOT a true ID/Locator split. > Instead, I'd say one has multiple Locator domains or multiple routing > domains with LISP. This claim makes no sense to me at all. LISP is a jack-up scheme, and in all jack-up schemes the end-end identification functionality stays with the upper "internetwork" layer. So there's no way the top namespace is a true locator, because it still has the end-end naming functionality. There's simply no way anything called a "locator" can have *any* end-end naming functionality. Sure, in the long term, it would be good to migrate that end-end naming functionality off to yet another namespace, but as long as we're trying to maintain backward compatability with IPv4, we are going to have some ugly kludges... > I think it would be cleaner, clearer, and more advantagous for LISP > itself if folks did not refer to LISP as an ID/Locator split approach. This debate seems particularly sterile. It is what it is (and see previous comment about "backward compatability with IPv4"). Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 03 23:41: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 1HNiV7-0003GN-6V; Sat, 03 Mar 2007 23:39:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNiV6-0003GF-AL for ram@iab.org; Sat, 03 Mar 2007 23:39:12 -0500 Received: from relay-dv.club-internet.fr ([194.158.96.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNiV4-0005io-RT for ram@iab.org; Sat, 03 Mar 2007 23:39:12 -0500 Received: from asus.club-internet.fr (i03m-212-195-38-17.d4.club-internet.fr [212.195.38.17]) by relay-dv.club-internet.fr (Postfix) with ESMTP id B518825602; Sun, 4 Mar 2007 05:38:49 +0100 (CET) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 Mar 2007 05:38:52 +0100 To: "Joel M. Halpern" , ram@iab.org From: JFC Morfin Subject: Re: [RAM] Terminology: ID/Locator split In-Reply-To: <7.0.1.0.0.20070302155218.039288d0@joelhalpern.com> References: <02307CA4-4F63-4CFA-B496-45BA62EC68F8@extremenetworks.com> <45E7E758.9030704@zurich.ibm.com> <7.0.1.0.0.20070302155218.039288d0@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070304043849.B518825602@relay-dv.club-internet.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 Dear Joel, your clear approach helps to make a complete synthesis. At 21:56 02/03/2007, Joel M. Halpern wrote: >Reading the various notes, and trying to state what the distinction >I have understood is, I end up with: > >One value is globally routable. >The other value is globally unique and is used by the host stack to >identify itself / its communicating partner. It is not globally routable. I add: One value being structured to globally identify the kind of function. (currently: a port) One value being structured to globally define the same virtual indexing for that function (currently: IPv6: Interface ID). >Whether that is a "split" a "separation" or something else probably >depends upon how it is done. Agreed. It looks like a progressive understanding from a default situation at the location. 1. there is the separation of the kind of targeted function through the port number. 2. there is the separation of the virtual address used by the function. Ex: http.1.1 where names are used for virtual hosts.. >It certainly gets harder to explain when for good (mostly evolution) >reasons we use the same structure of bits to fulfill both functions. LISP does not use the same structure (an IPv4 encapsulation can support an IPv6 datagram). It uses the same kind of numeric containers. I proposed to use the IPv6 header to support that 4 addressing orthogonal elements in splitting the IPv6 address. This required an IPv6 /3 block to be dedicated to that approach to keep it clean. At the expense of more space, LISP permits to pile these 4 informations, and any number of their extensions. - location and identification can use 4 (IPv4) or 16 (IPv6) bytes container, - virtual addressing a DNS label or a 4 to 16 bytes container, with the possibility of unlimited sub-virtual addressing with DNS labels or 4 to 16 bytes containers - function identification through a 2 bytes port or an unlimited pile of 4 to 16 bytes containers. The information is not _split_, it is orderly _concatenated_. However this requires a way to know the information to pile-in and when to peel it off. A simple rule could be to remove the top-of-the-pile-header and to put it at the end of the datagram, when it is the number of the reached "node" (including hosts, functions, and virtual index). - we then actually have a mix of addressing and a routing information. Each note knows it must forward the datagram towards the new top-of-the-pile node fixed for the network path, mobile (actual or possible mobility) for the host identification, virtual for the application indexing, and port for the function if supported through a 4 to 16 byte number). It can be the next neighbor or a very remote one. If something fails the packet can then come backward (putting the last the end information on the top of the header pile) until it can get forward again. This means that the "end to virtual end itinerary" has to be piled-up by the originating end. This is the function I call supervision which consists in knowing some of the corresponding elements on the nodes of the path and to pile the LISP header accordingly. >It gets really confused when as further transition we actually use >globally routable bit strings for the identifier. The considered information is only the indicator of the next node to reach. That indicator can be local, from any numbering system, or global the direct neighbor or a remote node. There is no impact on the LISP header as long as there is no conflict of indicator at any given node. If we are in a multi-topology environment there may be different ways to reach another node at different costs or classes of services. I suggest that it takes the least costing permitted path, or only the virtual adjencies of its own class of service. >At that point, I do have to agree that we don't have much of a >"split" any more. (Of course, the agreement of an approach with a >specific word is NOT the condition for it being or not being useful >to consider.) We have a concatenation of location, identification, function, application index indicators and of their extensions. >Yours, >Joel > >At 03:59 AM 3/2/2007, Brian E Carpenter wrote: >>I've already expressed my concern that the word "split" >>is wrong in itself for many of the solutions being >>considered. What we have in reality today are context- >>dependent locators, which in some contexts are used as >>identifiers for transport, security, applications or network >>management. The question really is whether we embrace >>this architecturally (which shim6 and lisp both do) >>or whether we try to change it by abolishing the >>context dependency (which is what a true split would >>do). See above. We are in a "protocol on a dumb wire" environment. The node to node chaining only considers indicators claimed by its neighbors. As long as there is no conflict they can be global or contextual. This, however, requires an important addition: supervisors must receive the information of the nodes, or through a predetermined topology description. When a nodes transmits its information one knows the information and that the node is LISP compatible. When a node does not transmit its information one knows that it is not LISP interoperable. IMHO, the LISP operating modules could be installed as OPES transmitting their data under OCP. It could then be assisted by OCP related call-out routing/access/reporting hosts forming a routing services network overlay [rfc 4037]. Routers could be operated through OPESed files. jfc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 04 11: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 1HNtSK-0000xG-U1; Sun, 04 Mar 2007 11:21:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNtSJ-0000x4-PZ for ram@iab.org; Sun, 04 Mar 2007 11:21:03 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNtSJ-00050Q-Gb for ram@iab.org; Sun, 04 Mar 2007 11:21:03 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [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 l24GKdm5050441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 4 Mar 2007 17:20:40 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Fwd: I-D ACTION:draft-bagnulo-pshim6-00.txt Date: Sun, 4 Mar 2007 17:20:46 +0100 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, ILJQX_SUBJ_NUMINWORD 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: 97adf591118a232206bdb5a27b217034 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 28-feb-2007, at 12:45, marcelo bagnulo braun wrote: > i have included in this draft some level of detail on how to do > proxies in shim6, in order to support unmodified hosts, allow some > middle boxes to perform egress path selection and provide PI > identifiers, so that we can have an idea of how this would look > like in the shim approach > Comments are welcome You say something to the effect that shim6 makes it hard to enforce TE. I would like to object to the notion that anyone GETS to "enforce" TE. If a host or user has internet access service, this means it, he or she gets to send and receive a certain amount of traffic per unit of time. Some light-weight influencing of this by ISPs can be beneficial to both the ISP and the user, but fundamentally, the user pays so the ISP is obligated to carry the traffic: no enforcing. Further, if the host is single homed the ISP doesn't get to do any traffic engineering either. Good writeup, but nothing surprising, as you say, most of this stuff has been talked about in shim6 circles before. The main problem that I see is deployment: it just needs too many little and not so little things to be changed in order to work. Nits: "globally routing addresses": this sounds strange and is also not 100% clear. Who is "we"? Didn't you write this alone? :-) You spelled my name wrong in the references section. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 04 11:53: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 1HNtwv-0004OH-Ui; Sun, 04 Mar 2007 11:52:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNtvA-0003BG-Qx for ram@ietf.org; Sun, 04 Mar 2007 11:50:52 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNtti-0000Yd-4V for ram@ietf.org; Sun, 04 Mar 2007 11:49:23 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [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 l24Gn9Jr050849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 4 Mar 2007 17:49:10 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@ietf.org From: Iljitsch van Beijnum Date: Sun, 4 Mar 2007 17:49:16 +0100 X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.2 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: 87a3f533bb300b99e2a18357f3c1563d Cc: Subject: [RAM] Pre-draft: mapper 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 Hi, Since draft submission is now closed but I want to get this out before the IETF meeting, I decided to write a short "pre-draft". No boilerplate or much in the way of formatting yet. You can find it at http://www.muada.com/drafts/draft-van-beijnum-mapper-00.txt Or just keep reading: A mapping protocol draft-van-beijnum-mapper-00.txt Introduction This document describes protocol that distributes mapping information. The protocol takes a namespace with no explicit hierarchy and allows data to be attached to any name in the namespace, providing the ability to query for the data attached to a given name, and be automatically informed of subsequent changes to this data. The purpose of this protocol is to distribute the location of decapsulation devices that are capable of receiving encapsulated IP packets, decapsulate them and deliver them to the holder of the destination IP address without the need for a prefix covering this IP address to be present in the BGP default-free zone. General overview The idea is that users of IP address space are connected to one or more ISPs (the examples will use two) in the following fashion: ISP A --- ISP B / \ / \ User 1 X User 2 \ / \ / ISP C --- ISP D where each ISP operates a network with routers that have one (sometimes more) of three functions: 1. Edge router: this type of router connects to customers 2. Border router: this type of router connects to other ISPs 3. Core router: these provide connectivity between edge and border routers Edge routers don't necessarily need a copy of the full default-free BGP routing table; they can forward packets according to a default route if need be. Also, in most cases, they don't need to be extremely fast because the majority of customers connects at modest speeds. Border routers don't need a copy of the full default-free table either; they only need routes for the destinations connected to the external networks they interface with. Border routers may need to be fast because a lot of traffic is exchanged between ISPs. Core routers need a full BGP table and they need to be fast: all the routing information and all the traffic comes together in these routers. The idea is to implement encapsulation and decapsulation devices close to the edge routers, where traffic volumes are relatively modest. Certain IP address prefixes are then no longer carried in BGP in the core or border routers. Rather, packets with these destinations are forwarded to an encapsulation device, which encapsulates the packets in some fashion and sends the packets on their way as per the encapsulating protocol and/or the address in the encapsulating header. The examples will assume IP-in-IP encapsulation, but other types are possible as well, such as direct / on demand fiber paths or MPLS. When the packets arrive at the decapsulation device close to the destination, they're decapsulated and forwarded to the destination using the destination IP address in the original IP packet. The routers between the encapsulation device and the decapsulation device now no longer need to have the IP address prefixes in question in their tables. The mapping protocol makes sure that encapsulation devices know which decapsulation devices serve a particular IP destination. Mapping protocol overview In addition to decapsulation devices that generate mapping information, and encapsulation devices that use mapping information, there are also authoritative mapping servers. The idea is that parts of the name/address space are served by a small number of authoritative servers. Decapsulation devices register their mappings with these servers, and encapsulation devices query the authoritative servers. A final type of mapping servers are the ones that only consolidate, cache and redistribute mapping information. Mapping information distributed in the protocol consists of: 1. Source: an AS number, a router identifier and a timestamp 2. Mapping data: for IP-in-IP, this would be the tunnel destination address 3. Refer to: a set of addresses that may be contacted for more detailed information 4. Source preference: traffic engineering information from the source This information is put into packets along with an indentifier, which is the IP prefix that the mapping information applies to. On its way from the decapsulation device to the authoritative server, the data is accompanied by an HMAC so the authoritative server knows the mapping data is authorized by the legitimate holder of the address space. A shared secret is communicated out of band. Additional security mechanisms may be defined at a later date. Authoritative and non-authoritative mapping servers consolidate sets of mapping data pertaining to the same identifier into a single message. This is possible because only mapping data with the same source AS and routing ID overwrites an earlier message. The timestamp is used to suppress duplicate messages. Mapping servers may also attach local preference information to aid traffic engineering. Operation In order to advertise mapping information, a decapsulation device must set up and maintain a TCP session towards one or more authoritative servers, possibly aided by intermediate non-authoritative servers. Encapsulation devices may either set up and maintain sessions towards authoritative servers (in practice probably to non-authoritative caching/redistributing servers). As long as the session remains, the encapsulating device may receive updates for the information it requested earlier. Alternatively, they can do a single lookup and then connect directly towards one or more decapsulation devices to learn reachability information directly, and/or request information that is more granular that what the mapping/flooding system can accommodate. An example of this would be host mobility. Discussion: for just PI without multihoming, it's enough to do a single lookup for mapping info, as this information isn't going to change. However, for multihoming, it's essential to be informed of changes very quickly: with only caching, the encapsulation device could be sending to a dead decapsulation device. An alternative approach would be to always cache, and let a decapsulation device reach back to the encapsulation device when the decapsulation device is no longer capable of delivering packets to a certain destination. With IP-in-IP this is easily done through the tunnel source address. However, this trades off reliability of the packet delivery against scalability of the mapper service. Note that both encapsulation and decapsulation devices can be implemented inside ISP networks or in end-user networks, or even in hosts. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 04 14:01:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNvup-0005u4-HR; Sun, 04 Mar 2007 13:58:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNvuo-0005rv-44 for ram@iab.org; Sun, 04 Mar 2007 13:58:38 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNvuj-0000uS-QR for ram@iab.org; Sun, 04 Mar 2007 13:58:38 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 44A281103CC for ; Sun, 4 Mar 2007 19:58:28 +0100 (CET) Received: from [163.117.203.117] (unknown [163.117.203.117]) by smtp02.uc3m.es (Postfix) with ESMTP id 4E4161103CD for ; Sun, 4 Mar 2007 19:58:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v624) Content-Transfer-Encoding: quoted-printable Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: marcelo bagnulo braun Date: Sun, 4 Mar 2007 19:58:28 +0100 X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: b94423d57458a72e07b422b40e685d94 Subject: [RAM] LISP threat analysis 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, I have performed a preliminary threat analysis for LISP. I guess that=20 some threats are missing, but here are some that i have been able to=20 identify with my current undersranding of LISP. I know that LISP does=20 not have security features yet, the goal of the draft is to cosnider=20 what type of threats need to be taken into account when designing the=20 security (i don't mean that all the threats described in the analysis=20 must be prevented, but just that they need to be considered in the=20 analysis at least) Since the 00 deadline already passed, i am sending it to the ml It will appear in the ID directory after prague i guess Regards, marcelo Network Working Group M. Bagnulo Internet-Draft Huawei Lab at UC3M Intended status: Informational March 4, 2007 Expires: September 5, 2007 Preliminary LISP Threat Analysis draft-bagnulo-lisp-threat-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document performs a preliminary threat analysis on the Locator/ID Separation Protocol (LISP) as defined in draft- = farinacci- lisp-00.txt. Bagnulo Expires September 5, 2007 [Page 1] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. Application Scenario . . . . . . . . . . . . . . . . . . . . . = 3 3. Threat analysis . . . . . . . . . . . . . . . . . . . . . . . = 4 3.1. Identity hijacking . . . . . . . . . . . . . . . . . . . . = 4 3.1.1. Attacker initiated communication (Hijacking a client identity) . . . . . . . . . . . . . . . . . . . = 4 3.1.2. Victim initiated communication (Hijacking a server identity) . . . . . . . . . . . . . . . . . . . . . . = 5 3.1.3. Intercepting ongoing communications (becoming a MITM) . . . . . . . . . . . . . . . . . . . . . . . . = 6 3.2. DoS attacks . . . . . . . . . . . . . . . . . . . . . . . = 7 3.2.1. Flooding a third party . . . . . . . . . . . . . . . . = 7 3.2.2. Preventing future communications . . . . . . . . . . . = 8 3.2.3. Interrupt ongoing communication . . . . . . . . . . . = 8 3.2.4. DoS attacks against LISP infrastructure . . . . . . . = 8 4. Security considerations . . . . . . . . . . . . . . . . . . . = 8 5. Normative References . . . . . . . . . . . . . . . . . . . . . = 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . = 9 Intellectual Property and Copyright Statements . . . . . . . . . . = 10 Bagnulo Expires September 5, 2007 [Page 2] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 1. Introduction The first version of the Locator/ID Separation Protocol (LISP) is defined in draft-farinacci-lisp-00.txt [1]. This first version of the LIPS specification does not contain any security mechanisms. = The goal of this document is to identify the different threats in the current LISP protocol in order to understand the security mechanisms that are needed to protect the LISP protocol. 2. Application Scenario We will consider the following application scenario. +----+ | HA | +----+ | EID: P1:IIDA ----------------- | | RLOC: P1:IIDLR1, P2:IIDLR2 +----+ +----+ |LR1 | |LR2 | +----+ +----+ | | | | +----+ +----+ |ISP1| |ISP2| +----+ +----+ +----+ | | +--| HC | IPC +----------------+ | +----+ | |--+ | Internet | +----+ | |-----| AT | IPAT +----------------+ +----+ | | +----+ +----+ |LR3 | | HB | +----+ +----+ | | EID=3DIPB RLOC=3DIPLR3 -------------------- LR [ETH] LISP Router that behaves bots as ITR and ETR In the depicted scenario we have two LISP capable sites. One of the sites, depicted on top of the figure, is multihomed to ISP1 and = ISP2. Bagnulo Expires September 5, 2007 [Page 3] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 We assume that we are using LISP1, so one of the routable addresses is used as EID, let's say that for host HA P1:IIDA is used as EID. In addition, the locators for that host will be the two addresses of the exit routers that are playing the role of ITR namely LR1 and = LR2, so RLOCs are P1:IIDLR1 and P2:IIDLR2. (LR stands for LISP router since it plays both the roles of ITR and ETR). The other LISP capable site is the one depicted in the lower part of the figure and it has a single ISP and a single ITR/ETR namely, LR3. Host H3 located in this site has IPB as EID and the address of the LR3, LPLR3 as RLOC. Since we are using LISP1, IPB is a routable address Hosts HC and AT are other hosts in the Internet, with addresses IPC and IPAT respectively. HA, HB and HC are victims and AT is the attacker. 3. Threat analysis Off-path attacker assumption We will limit the considered attacks to those where the attacker is not located along the path used to route packets of the = communication being attacked. 3.1. Identity hijacking In the attacks considered in this section the attacker will try to hijack the identity of one victim on the eyes of another victim. This means that two parties are deceived, one that thinks that is communicating with the owner of a given identify, but it is communicating with the attacker instead and the party whose identify is being stolen. 3.1.1. Attacker initiated communication (Hijacking a client identity) In this case, the attacker will initiate a communication with one victim pretending to be someone else. In the scenario above, the attacker AT will try to initiate a communication with HA pretending to be HC. In order to do that it will send a LISP packet with the following parameters: - Destination RLOC (outer header destination address): P1:IIDA Bagnulo Expires September 5, 2007 [Page 4] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 - Destination EID (Inner header destination address): P1:IIDA - Source RLOC (outer header source address): IPAT - Source EID (inner header source address): IPC The packet will be received by LR1 who will generate the ICMP = EID-to- RLOC Mapping message back to IPAT and will store the EID to RLOC mapping information for the received data packet as described in section 6.2 of draft-farinacci- lisp-00. The EID to RLOC mapping information stored at LR1 contains the following information: EID =3D HC, RLOC=3DIPAT In this case HA will be communicating with the attacker AT but HA believes that he is communicating with HC. HC identity has been stolen by AT in the eyes of HA. A similar attack could be launched using ICMP EID-to-RLOC Mapping messages instead of data packets. This would work in the following way. First that attacker sends an ICMP EID-to-RLOC Mapping message containing the false EID to RLOC mapping information and then it starts sending data packets using such state. 3.1.2. Victim initiated communication (Hijacking a server identity) In the previous section, the attacker is hijacking the identity of a client, since the attacker is the one that initiates the communication. While this is problematic, a much more ambitious attacks would to hijack the identity of a server, i.e. to hijack the identity of a server when the victim initiates a communication towards the server. This is also possible with LISP. It would work in the following = way. Suppose that HC is a server that HA uses regularly (e.g. a newspaper web site) Suppose that AT wants that future communication initiated by HA to = HC are directed to AT i.e. AT wants to hijack HC identity for all the communications initiated by HA. In order to do that, AT performs the following actions. It first needs to install false EID-to-RLOC mapping information in LR1. In order to do that, it has two options. It either sends a data packet containing the following information - Destination RLOC (outer header destination address): P1:IIDA Bagnulo Expires September 5, 2007 [Page 5] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 - Destination EID (Inner header destination address): P1:IIDA - Source RLOC (outer header source address): IPAT - Source EID (inner header source address): IPC The data packet could be a UDP packet that will be discarded upon reception because there is no process listening in the requested = port or an ICMP EID-to-RLOC Mapping message containing the mapping information from EID HC and RLOC IPAT. In any case LR1 will store that in order to reach IPC it must tunnel the packets to IPAT. However, there is no actual ongoing communication between HA and HC at the moment, so the attack has no effect so far. The attacker = must then keep the EID to RLOC mapping information alive in LR1 for when HA decides to initiate a communication to HC. The attacker can do that by sending periodic data packets or ICMP EID-to-RLOC Mapping messages with the same information detailed before. Suppose that at any point in the future, HA decides to initiate a communication with HC. It will send a data packet with destination address IPC. The data packet will be intercepted by LR1 and tunnelled to the attacker at IPAT, since this is the mapping information available at LR1. Note that these attacks affect all future communications started by HA and that it affects communication initiated by HA. 3.1.3. Intercepting ongoing communications (becoming a MITM) In the two previous sections, we have considered the case where the attacker wants to hijack a future communication pretending to be one of the involved parties. In this section we will consider the case where there is an ongoing communication and the attacker wants to hijack the ongoing communication. Suppose that there is an ongoing communication between HA and HB. = In this case, LR1 contains a mapping between EID=3DIPB and RLOC=3DIPLR3. LR3 contain a mapping between EID=3D P1:IIDA and RLOC=3DP1:IIDLR1, = P2: IIDLR2. Suppose now that AT sends two packets, one to LR1 and another to = LR3. These again can be data packets or ICMP EID-to-RLOC Mapping = messages. Bagnulo Expires September 5, 2007 [Page 6] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 In any case, the packet sent to LR1 will contain mapping information of EID=3DIPB and RLOC=3DIPAT. The packet sent to LR3 will contain mapping information EID=3DP1:IIDA and RLOC=3DIPAT. (One may think that ingress filtering could help here, but note that the attacker is sending packets from the claimed locator, so ingress filters won't be of any use to prevent this attack) The result is that LR1 will tunnel packets addressed to HB to the attacker at IPAT and LR2 will tunnel packets addressed to HA to the attacker at IPAT. The attacker has now placed himself as a man in the middle in the communication. It can either modify packets or simply sniff them. 3.2. DoS attacks In this section, we describe DoS attacks related to LISP. 3.2.1. Flooding a third party In this case, the attacker AT wants to use HA to flood a victim HC. In order to do that, it first initiates a communication with HA and starts a download of a heavy flow. Once that the flow is downloading, it redirects the heavy flow towards HC, flooding it. This is performed in the following way. AT initiates a communication with HA. In this case, AT uses IPAT as EID and IPAT as RLOC. This mapping information is stored in LR1 using either a data packet or an ICMP EID-to- RLOC Mapping message. AT then starts downloading a heavy flow form HA. At some point = then, AT redirects the flow towards HC. It can do so by including IPC as = a RLOC for the EID IPAT that is being used in the communication that = is downloading the heavy flow. The IPC RLOC could be included since = the beginning with a low priority and now simply send a new ICMP EID-to- RLOC Mapping message with a higher priority to IPC. In any case the result is that the flow will flood HC. It should be noted that in some cases, in order to keep the flow going, it is necessary that the receiver sends some ACK packets or similar. In this case, it is possible that the attacker can send such packets, since EID IPAT in LR1 can contain two valid RLOCs i.e. IPAT and IPC. In this case, if IPC has higher priority that IPAT, LR1 will send packets to IPC but will accept packets coming from = IPAT as valid packets from the EID IPAT. In this case, the attacker = could send ACK packets from its own location, and keep the flooding going towards IPC. Bagnulo Expires September 5, 2007 [Page 7] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 3.2.2. Preventing future communications This case is similar to the one described in section Victim = initiated communication (Hijacking a server identity), but only that instead = of the attackers RLOC, a back hole IP address is included as the RLOC for a given EID. The result is that the traffic addressed to the = EID is sent to a black hole, resulting in a DoS attacks form communications to that EID. Note that since LISP allows EID to be aggregated, the EIDs to be aggregated, this attack could affect really big prefixes of EIDs, in particular an attack to the prefix 0.0.0.0/0 would result in = blocking all communications of the site. 3.2.3. Interrupt ongoing communication This case is similar to the one described in the section = Intercepting ongoing communications (becoming a MITM) with the only difference that an back hole IP address is included as RLOC for the ongoing communication, terminating it. 3.2.4. DoS attacks against LISP infrastructure Another type of DoS attacks that must be considered are the DoS attacks against the LISP architecture itself. In particular LISP routers (ITR and ETR) are susceptible to DoS attacks. LISP routers store information about EID-to- RLOC = mappings. They learn that information from data packets and from ICMP = messages. An attacker could massively generate either tunnelled data packets = or ICMP packets so that the router cache is overflowed. The result is that routers will not be able to store legitimate EID-to-RLOC = mapping information and that LISP features will be annulled. (in the case of using non routable EIDs, all communication would be annulled if LISP functionality is not available) 4. Security considerations All this note considers security issues of the LISP protocol 5. Normative References [1] Farinacci, D., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-00 (work in progress), January 2007. Bagnulo Expires September 5, 2007 [Page 8] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 Author's Address Marcelo Bagnulo Huawei Lab at UC3M Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Bagnulo Expires September 5, 2007 [Page 9] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on = an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE = REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST = AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE = OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed = to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. = Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use = of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository = at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bagnulo Expires September 5, 2007 [Page 10] =0C =20= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 04 14:01:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNvuq-0005uF-RI; Sun, 04 Mar 2007 13:58:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNvup-0005tZ-2Y for ram@iab.org; Sun, 04 Mar 2007 13:58:39 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNvun-0000wC-Jq for ram@iab.org; Sun, 04 Mar 2007 13:58:39 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 233BD1103CD; Sun, 4 Mar 2007 19:58:32 +0100 (CET) Received: from [163.117.203.117] (unknown [163.117.203.117]) by smtp02.uc3m.es (Postfix) with ESMTP id D80FF1103D2; Sun, 4 Mar 2007 19:58:31 +0100 (CET) In-Reply-To: References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <31abbca5b4a374d679cfe3dbe02ad85a@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Fwd: I-D ACTION:draft-bagnulo-pshim6-00.txt Date: Sun, 4 Mar 2007 17:55:09 +0100 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Iljitsch, thanks for the feedback El 04/03/2007, a las 17:20, Iljitsch van Beijnum escribi=F3: > On 28-feb-2007, at 12:45, marcelo bagnulo braun wrote: > >> i have included in this draft some level of detail on how to do=20 >> proxies in shim6, in order to support unmodified hosts, allow some=20 >> middle boxes to perform egress path selection and provide PI=20 >> identifiers, so that we can have an idea of how this would look like=20= >> in the shim approach > >> Comments are welcome > > You say something to the effect that shim6 makes it hard to enforce = TE. > What i wanted to say is that if for some reason (e.g. backward=20 compatibility with non-shim6 capable hosts) multiple routable addresses=20= are presented to the host within the multihomed site and it is up to=20 the host to select the source address among them, then it can override=20= the TE policies of the site and then the network admin of the site=20 cannot enforce TE, since the host can override the router decisions. However, if the hosts within the multihomed site are configured with=20 only one non globally routable ID, and it is only up to the P-shim to=20 select the locators to be used, then the one configuring the P-shim box=20= is the one that is defining the TE and also enforcing it. > I would like to object to the notion that anyone GETS to "enforce" TE.=20= > If a host or user has internet access service, this means it, he or=20 > she gets to send and receive a certain amount of traffic per unit of=20= > time. Some light-weight influencing of this by ISPs can be beneficial=20= > to both the ISP and the user, but fundamentally, the user pays so the=20= > ISP is obligated to carry the traffic: no enforcing. Further, if the=20= > host is single homed the ISP doesn't get to do any traffic engineering=20= > either. > > Good writeup, but nothing surprising, as you say, most of this stuff=20= > has been talked about in shim6 circles before. The main problem that I=20= > see is deployment: it just needs too many little and not so little=20 > things to be changed in order to work. you may be right > > Nits: > > "globally routing addresses": this sounds strange and is also not 100%=20= > clear. > should read globally routable address > Who is "we"? Didn't you write this alone? :-) > :-) it is my literary style and/or my schizophrenic personality > You spelled my name wrong in the references section. > > i am sorry about that... i should have learned it by now... Regards, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 04 14:01:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNvup-0005u4-HR; Sun, 04 Mar 2007 13:58:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNvuo-0005rv-44 for ram@iab.org; Sun, 04 Mar 2007 13:58:38 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNvuj-0000uS-QR for ram@iab.org; Sun, 04 Mar 2007 13:58:38 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 44A281103CC for ; Sun, 4 Mar 2007 19:58:28 +0100 (CET) Received: from [163.117.203.117] (unknown [163.117.203.117]) by smtp02.uc3m.es (Postfix) with ESMTP id 4E4161103CD for ; Sun, 4 Mar 2007 19:58:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v624) Content-Transfer-Encoding: quoted-printable Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: marcelo bagnulo braun Date: Sun, 4 Mar 2007 19:58:28 +0100 X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: b94423d57458a72e07b422b40e685d94 Subject: [RAM] LISP threat analysis 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, I have performed a preliminary threat analysis for LISP. I guess that=20 some threats are missing, but here are some that i have been able to=20 identify with my current undersranding of LISP. I know that LISP does=20 not have security features yet, the goal of the draft is to cosnider=20 what type of threats need to be taken into account when designing the=20 security (i don't mean that all the threats described in the analysis=20 must be prevented, but just that they need to be considered in the=20 analysis at least) Since the 00 deadline already passed, i am sending it to the ml It will appear in the ID directory after prague i guess Regards, marcelo Network Working Group M. Bagnulo Internet-Draft Huawei Lab at UC3M Intended status: Informational March 4, 2007 Expires: September 5, 2007 Preliminary LISP Threat Analysis draft-bagnulo-lisp-threat-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document performs a preliminary threat analysis on the Locator/ID Separation Protocol (LISP) as defined in draft- = farinacci- lisp-00.txt. Bagnulo Expires September 5, 2007 [Page 1] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. Application Scenario . . . . . . . . . . . . . . . . . . . . . = 3 3. Threat analysis . . . . . . . . . . . . . . . . . . . . . . . = 4 3.1. Identity hijacking . . . . . . . . . . . . . . . . . . . . = 4 3.1.1. Attacker initiated communication (Hijacking a client identity) . . . . . . . . . . . . . . . . . . . = 4 3.1.2. Victim initiated communication (Hijacking a server identity) . . . . . . . . . . . . . . . . . . . . . . = 5 3.1.3. Intercepting ongoing communications (becoming a MITM) . . . . . . . . . . . . . . . . . . . . . . . . = 6 3.2. DoS attacks . . . . . . . . . . . . . . . . . . . . . . . = 7 3.2.1. Flooding a third party . . . . . . . . . . . . . . . . = 7 3.2.2. Preventing future communications . . . . . . . . . . . = 8 3.2.3. Interrupt ongoing communication . . . . . . . . . . . = 8 3.2.4. DoS attacks against LISP infrastructure . . . . . . . = 8 4. Security considerations . . . . . . . . . . . . . . . . . . . = 8 5. Normative References . . . . . . . . . . . . . . . . . . . . . = 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . = 9 Intellectual Property and Copyright Statements . . . . . . . . . . = 10 Bagnulo Expires September 5, 2007 [Page 2] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 1. Introduction The first version of the Locator/ID Separation Protocol (LISP) is defined in draft-farinacci-lisp-00.txt [1]. This first version of the LIPS specification does not contain any security mechanisms. = The goal of this document is to identify the different threats in the current LISP protocol in order to understand the security mechanisms that are needed to protect the LISP protocol. 2. Application Scenario We will consider the following application scenario. +----+ | HA | +----+ | EID: P1:IIDA ----------------- | | RLOC: P1:IIDLR1, P2:IIDLR2 +----+ +----+ |LR1 | |LR2 | +----+ +----+ | | | | +----+ +----+ |ISP1| |ISP2| +----+ +----+ +----+ | | +--| HC | IPC +----------------+ | +----+ | |--+ | Internet | +----+ | |-----| AT | IPAT +----------------+ +----+ | | +----+ +----+ |LR3 | | HB | +----+ +----+ | | EID=3DIPB RLOC=3DIPLR3 -------------------- LR [ETH] LISP Router that behaves bots as ITR and ETR In the depicted scenario we have two LISP capable sites. One of the sites, depicted on top of the figure, is multihomed to ISP1 and = ISP2. Bagnulo Expires September 5, 2007 [Page 3] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 We assume that we are using LISP1, so one of the routable addresses is used as EID, let's say that for host HA P1:IIDA is used as EID. In addition, the locators for that host will be the two addresses of the exit routers that are playing the role of ITR namely LR1 and = LR2, so RLOCs are P1:IIDLR1 and P2:IIDLR2. (LR stands for LISP router since it plays both the roles of ITR and ETR). The other LISP capable site is the one depicted in the lower part of the figure and it has a single ISP and a single ITR/ETR namely, LR3. Host H3 located in this site has IPB as EID and the address of the LR3, LPLR3 as RLOC. Since we are using LISP1, IPB is a routable address Hosts HC and AT are other hosts in the Internet, with addresses IPC and IPAT respectively. HA, HB and HC are victims and AT is the attacker. 3. Threat analysis Off-path attacker assumption We will limit the considered attacks to those where the attacker is not located along the path used to route packets of the = communication being attacked. 3.1. Identity hijacking In the attacks considered in this section the attacker will try to hijack the identity of one victim on the eyes of another victim. This means that two parties are deceived, one that thinks that is communicating with the owner of a given identify, but it is communicating with the attacker instead and the party whose identify is being stolen. 3.1.1. Attacker initiated communication (Hijacking a client identity) In this case, the attacker will initiate a communication with one victim pretending to be someone else. In the scenario above, the attacker AT will try to initiate a communication with HA pretending to be HC. In order to do that it will send a LISP packet with the following parameters: - Destination RLOC (outer header destination address): P1:IIDA Bagnulo Expires September 5, 2007 [Page 4] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 - Destination EID (Inner header destination address): P1:IIDA - Source RLOC (outer header source address): IPAT - Source EID (inner header source address): IPC The packet will be received by LR1 who will generate the ICMP = EID-to- RLOC Mapping message back to IPAT and will store the EID to RLOC mapping information for the received data packet as described in section 6.2 of draft-farinacci- lisp-00. The EID to RLOC mapping information stored at LR1 contains the following information: EID =3D HC, RLOC=3DIPAT In this case HA will be communicating with the attacker AT but HA believes that he is communicating with HC. HC identity has been stolen by AT in the eyes of HA. A similar attack could be launched using ICMP EID-to-RLOC Mapping messages instead of data packets. This would work in the following way. First that attacker sends an ICMP EID-to-RLOC Mapping message containing the false EID to RLOC mapping information and then it starts sending data packets using such state. 3.1.2. Victim initiated communication (Hijacking a server identity) In the previous section, the attacker is hijacking the identity of a client, since the attacker is the one that initiates the communication. While this is problematic, a much more ambitious attacks would to hijack the identity of a server, i.e. to hijack the identity of a server when the victim initiates a communication towards the server. This is also possible with LISP. It would work in the following = way. Suppose that HC is a server that HA uses regularly (e.g. a newspaper web site) Suppose that AT wants that future communication initiated by HA to = HC are directed to AT i.e. AT wants to hijack HC identity for all the communications initiated by HA. In order to do that, AT performs the following actions. It first needs to install false EID-to-RLOC mapping information in LR1. In order to do that, it has two options. It either sends a data packet containing the following information - Destination RLOC (outer header destination address): P1:IIDA Bagnulo Expires September 5, 2007 [Page 5] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 - Destination EID (Inner header destination address): P1:IIDA - Source RLOC (outer header source address): IPAT - Source EID (inner header source address): IPC The data packet could be a UDP packet that will be discarded upon reception because there is no process listening in the requested = port or an ICMP EID-to-RLOC Mapping message containing the mapping information from EID HC and RLOC IPAT. In any case LR1 will store that in order to reach IPC it must tunnel the packets to IPAT. However, there is no actual ongoing communication between HA and HC at the moment, so the attack has no effect so far. The attacker = must then keep the EID to RLOC mapping information alive in LR1 for when HA decides to initiate a communication to HC. The attacker can do that by sending periodic data packets or ICMP EID-to-RLOC Mapping messages with the same information detailed before. Suppose that at any point in the future, HA decides to initiate a communication with HC. It will send a data packet with destination address IPC. The data packet will be intercepted by LR1 and tunnelled to the attacker at IPAT, since this is the mapping information available at LR1. Note that these attacks affect all future communications started by HA and that it affects communication initiated by HA. 3.1.3. Intercepting ongoing communications (becoming a MITM) In the two previous sections, we have considered the case where the attacker wants to hijack a future communication pretending to be one of the involved parties. In this section we will consider the case where there is an ongoing communication and the attacker wants to hijack the ongoing communication. Suppose that there is an ongoing communication between HA and HB. = In this case, LR1 contains a mapping between EID=3DIPB and RLOC=3DIPLR3. LR3 contain a mapping between EID=3D P1:IIDA and RLOC=3DP1:IIDLR1, = P2: IIDLR2. Suppose now that AT sends two packets, one to LR1 and another to = LR3. These again can be data packets or ICMP EID-to-RLOC Mapping = messages. Bagnulo Expires September 5, 2007 [Page 6] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 In any case, the packet sent to LR1 will contain mapping information of EID=3DIPB and RLOC=3DIPAT. The packet sent to LR3 will contain mapping information EID=3DP1:IIDA and RLOC=3DIPAT. (One may think that ingress filtering could help here, but note that the attacker is sending packets from the claimed locator, so ingress filters won't be of any use to prevent this attack) The result is that LR1 will tunnel packets addressed to HB to the attacker at IPAT and LR2 will tunnel packets addressed to HA to the attacker at IPAT. The attacker has now placed himself as a man in the middle in the communication. It can either modify packets or simply sniff them. 3.2. DoS attacks In this section, we describe DoS attacks related to LISP. 3.2.1. Flooding a third party In this case, the attacker AT wants to use HA to flood a victim HC. In order to do that, it first initiates a communication with HA and starts a download of a heavy flow. Once that the flow is downloading, it redirects the heavy flow towards HC, flooding it. This is performed in the following way. AT initiates a communication with HA. In this case, AT uses IPAT as EID and IPAT as RLOC. This mapping information is stored in LR1 using either a data packet or an ICMP EID-to- RLOC Mapping message. AT then starts downloading a heavy flow form HA. At some point = then, AT redirects the flow towards HC. It can do so by including IPC as = a RLOC for the EID IPAT that is being used in the communication that = is downloading the heavy flow. The IPC RLOC could be included since = the beginning with a low priority and now simply send a new ICMP EID-to- RLOC Mapping message with a higher priority to IPC. In any case the result is that the flow will flood HC. It should be noted that in some cases, in order to keep the flow going, it is necessary that the receiver sends some ACK packets or similar. In this case, it is possible that the attacker can send such packets, since EID IPAT in LR1 can contain two valid RLOCs i.e. IPAT and IPC. In this case, if IPC has higher priority that IPAT, LR1 will send packets to IPC but will accept packets coming from = IPAT as valid packets from the EID IPAT. In this case, the attacker = could send ACK packets from its own location, and keep the flooding going towards IPC. Bagnulo Expires September 5, 2007 [Page 7] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 3.2.2. Preventing future communications This case is similar to the one described in section Victim = initiated communication (Hijacking a server identity), but only that instead = of the attackers RLOC, a back hole IP address is included as the RLOC for a given EID. The result is that the traffic addressed to the = EID is sent to a black hole, resulting in a DoS attacks form communications to that EID. Note that since LISP allows EID to be aggregated, the EIDs to be aggregated, this attack could affect really big prefixes of EIDs, in particular an attack to the prefix 0.0.0.0/0 would result in = blocking all communications of the site. 3.2.3. Interrupt ongoing communication This case is similar to the one described in the section = Intercepting ongoing communications (becoming a MITM) with the only difference that an back hole IP address is included as RLOC for the ongoing communication, terminating it. 3.2.4. DoS attacks against LISP infrastructure Another type of DoS attacks that must be considered are the DoS attacks against the LISP architecture itself. In particular LISP routers (ITR and ETR) are susceptible to DoS attacks. LISP routers store information about EID-to- RLOC = mappings. They learn that information from data packets and from ICMP = messages. An attacker could massively generate either tunnelled data packets = or ICMP packets so that the router cache is overflowed. The result is that routers will not be able to store legitimate EID-to-RLOC = mapping information and that LISP features will be annulled. (in the case of using non routable EIDs, all communication would be annulled if LISP functionality is not available) 4. Security considerations All this note considers security issues of the LISP protocol 5. Normative References [1] Farinacci, D., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-00 (work in progress), January 2007. Bagnulo Expires September 5, 2007 [Page 8] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 Author's Address Marcelo Bagnulo Huawei Lab at UC3M Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Bagnulo Expires September 5, 2007 [Page 9] =0C Internet-Draft Preliminary LISP Threat Analysis March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on = an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE = REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST = AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE = OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed = to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. = Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use = of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository = at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bagnulo Expires September 5, 2007 [Page 10] =0C =20= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 04 14:01:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNvuq-0005uF-RI; Sun, 04 Mar 2007 13:58:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNvup-0005tZ-2Y for ram@iab.org; Sun, 04 Mar 2007 13:58:39 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNvun-0000wC-Jq for ram@iab.org; Sun, 04 Mar 2007 13:58:39 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 233BD1103CD; Sun, 4 Mar 2007 19:58:32 +0100 (CET) Received: from [163.117.203.117] (unknown [163.117.203.117]) by smtp02.uc3m.es (Postfix) with ESMTP id D80FF1103D2; Sun, 4 Mar 2007 19:58:31 +0100 (CET) In-Reply-To: References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <31abbca5b4a374d679cfe3dbe02ad85a@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Fwd: I-D ACTION:draft-bagnulo-pshim6-00.txt Date: Sun, 4 Mar 2007 17:55:09 +0100 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Iljitsch, thanks for the feedback El 04/03/2007, a las 17:20, Iljitsch van Beijnum escribi=F3: > On 28-feb-2007, at 12:45, marcelo bagnulo braun wrote: > >> i have included in this draft some level of detail on how to do=20 >> proxies in shim6, in order to support unmodified hosts, allow some=20 >> middle boxes to perform egress path selection and provide PI=20 >> identifiers, so that we can have an idea of how this would look like=20= >> in the shim approach > >> Comments are welcome > > You say something to the effect that shim6 makes it hard to enforce = TE. > What i wanted to say is that if for some reason (e.g. backward=20 compatibility with non-shim6 capable hosts) multiple routable addresses=20= are presented to the host within the multihomed site and it is up to=20 the host to select the source address among them, then it can override=20= the TE policies of the site and then the network admin of the site=20 cannot enforce TE, since the host can override the router decisions. However, if the hosts within the multihomed site are configured with=20 only one non globally routable ID, and it is only up to the P-shim to=20 select the locators to be used, then the one configuring the P-shim box=20= is the one that is defining the TE and also enforcing it. > I would like to object to the notion that anyone GETS to "enforce" TE.=20= > If a host or user has internet access service, this means it, he or=20 > she gets to send and receive a certain amount of traffic per unit of=20= > time. Some light-weight influencing of this by ISPs can be beneficial=20= > to both the ISP and the user, but fundamentally, the user pays so the=20= > ISP is obligated to carry the traffic: no enforcing. Further, if the=20= > host is single homed the ISP doesn't get to do any traffic engineering=20= > either. > > Good writeup, but nothing surprising, as you say, most of this stuff=20= > has been talked about in shim6 circles before. The main problem that I=20= > see is deployment: it just needs too many little and not so little=20 > things to be changed in order to work. you may be right > > Nits: > > "globally routing addresses": this sounds strange and is also not 100%=20= > clear. > should read globally routable address > Who is "we"? Didn't you write this alone? :-) > :-) it is my literary style and/or my schizophrenic personality > You spelled my name wrong in the references section. > > i am sorry about that... i should have learned it by now... Regards, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 05 09:03:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODkx-0005kJ-PH; Mon, 05 Mar 2007 09:01:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HODkw-0005k8-GQ for ram@iab.org; Mon, 05 Mar 2007 09:01:38 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HODkv-0007dU-4f for ram@iab.org; Mon, 05 Mar 2007 09:01:38 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5B3EE198643 for ; Mon, 5 Mar 2007 16:01:29 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1FAD419863C for ; Mon, 5 Mar 2007 16:01:29 +0200 (EET) Message-ID: <45EC22BA.7050207@piuha.net> Date: Mon, 05 Mar 2007 16:01:30 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: ram@iab.org 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: b19722fc8d3865b147c75ae2495625f2 Subject: [RAM] routing and addressing meetings in Prague 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 all, We are planning to talk about the routing and addressing topic in Prague in a number of different meetings. Wednesday 1830-1930, Plenary -- http://www.arkko.com/ietf/ietf-68/ietf68_roap_agenda.txt This is a short report on where we are with this problem and what aspects of it the IETF can address. Thursday 0900-1130, INTAREA -- http://www3.ietf.org/proceedings/07mar/agenda/intarea.txt This is an architectural discussion about future IETF work on identifier-locator split and multi-level locator designs that may help issues with routing scalability and other issues in the long term. Thursday 1300-1500, RTGAREA -- (no agenda available yet) This meeting focuses on what we could do with BGP to address some aspects of the problem in the short term. Saturday March 17th, RRG -- http://www1.tools.ietf.org/group/irtf/trac/wiki/RRG This is a research group discussion on rechartering the RRG to look at new architectural approaches (including clean slate designs). Comments and suggestions appreciated. Jari, Mark, and Ross _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 05 11:10: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 1HOFjZ-0001qk-D6; Mon, 05 Mar 2007 11:08:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOFjY-0001qd-1L for ram@iab.org; Mon, 05 Mar 2007 11:08:20 -0500 Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOFjW-0002ol-LI for ram@iab.org; Mon, 05 Mar 2007 11:08:20 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l25G8Htd102214 for ; Mon, 5 Mar 2007 16:08:17 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l25G8Hj71503232 for ; Mon, 5 Mar 2007 16:08:17 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l25G8GPk012441 for ; Mon, 5 Mar 2007 16:08:16 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l25G8GZt012429; Mon, 5 Mar 2007 16:08:16 GMT Received: from [9.145.135.171] (sig-9-145-135-171.de.ibm.com [9.145.135.171]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA223848; Mon, 5 Mar 2007 17:08:15 +0100 Message-ID: <45EC406E.1060901@zurich.ibm.com> Date: Mon, 05 Mar 2007 17:08:14 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [RAM] PASH: Another SHIM6 proxying draft, in addition to pshim6 References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> <0B6CD3B7-0B90-4E9F-AEC0-55E417865F2E@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 I have a couple of questions about pash. pshim6 finds a need for a DNS ALG. Does pash have the same need? How will pash deal with TCP relays along the path (which recompute the TCP checksum)? This is an open issue for shim6 and pshim6. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 05 13:57:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOIMT-0003sg-5U; Mon, 05 Mar 2007 13:56:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOIMS-0003sY-GQ; Mon, 05 Mar 2007 13:56:40 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOIMR-0002d2-6p; Mon, 05 Mar 2007 13:56:40 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 05 Mar 2007 10:56:39 -0800 X-IronPort-AV: i="4.14,251,1170662400"; d="scan'208"; a="397043781:sNHT145800182" 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 l25IucA6024209; Mon, 5 Mar 2007 10:56:38 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l25IubYs005977; Mon, 5 Mar 2007 18:56:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 10:56:38 -0800 Received: from [171.71.55.245] ([171.71.55.245]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 10:56:37 -0800 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <7ADCE0AB-A94B-4FDC-A207-FABAB5BB0720@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: rrg , ram@ietf.org, architecture-discuss@ietf.org From: Tony Li Date: Mon, 5 Mar 2007 10:56:35 -0800 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Mar 2007 18:56:37.0618 (UTC) FILETIME=[00A8ED20:01C75F58] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=158; t=1173120998; x=1173984998; 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:=20RRG=20meeting=20change=20of=20venue |Sender:=20; bh=wKCQicYlQBRqsb5ffcU5fKvWUKKGsym8iJyDotust5U=; b=im3jNoYjPUGWdxDgHAX6ACWOoMRyy+4S8cnmq8uzmOwZNo7/84tv+8+vE+AyxPWNRhCEqSiP TmdjcUifypF7sViQHdEpl9Cx3y98br2YrZ3O6zsFbz+iEwpZfvsGV/UZ; 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: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [RAM] RRG meeting change of venue 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 Please note that the RRG meeting on Saturday, March 17th has changed rooms. It will now be held in the Madrid/Vienna room. Thanks, Lixia & Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 05 17:15: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 1HOLRe-0001H9-BO; Mon, 05 Mar 2007 17:14:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOLRc-0001Gh-Bb for ram@iab.org; Mon, 05 Mar 2007 17:14:12 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOLRZ-0005C1-Ep for ram@iab.org; Mon, 05 Mar 2007 17:14:12 -0500 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 l25ME8KE004713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Mar 2007 14:14:08 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l25ME5iA009980; Mon, 5 Mar 2007 14:14:07 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 14:14:06 -0800 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] routing and addressing meetings in Prague Date: Mon, 5 Mar 2007 14:14:07 -0800 Message-ID: In-Reply-To: <45EC22BA.7050207@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] routing and addressing meetings in Prague Thread-Index: AcdfLu8gst2AeqJXT+aRR4AYBLJBuwARJizg References: <45EC22BA.7050207@piuha.net> From: "Narayanan, Vidya" To: "Jari Arkko" , X-OriginalArrivalTime: 05 Mar 2007 22:14:06.0997 (UTC) FILETIME=[9770AC50:01C75F73] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Could someone please post a list of relevant documents that have already been written on this topic?=20 Thanks, Vidya=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Monday, March 05, 2007 6:02 AM > To: ram@iab.org > Subject: [RAM] routing and addressing meetings in Prague >=20 > Hi all, >=20 > We are planning to talk about the routing and addressing=20 > topic in Prague in a number of different meetings. >=20 > Wednesday 1830-1930, Plenary -- > http://www.arkko.com/ietf/ietf-68/ietf68_roap_agenda.txt >=20 > This is a short report on where we are with this problem and what > aspects of it the IETF can address. >=20 > Thursday 0900-1130, INTAREA -- > http://www3.ietf.org/proceedings/07mar/agenda/intarea.txt >=20 > This is an architectural discussion about future IETF work on > identifier-locator split and multi-level locator designs=20 > that may help > issues with routing scalability and other issues in the long term. >=20 > Thursday 1300-1500, RTGAREA -- (no agenda available yet) >=20 > This meeting focuses on what we could do with BGP to address > some aspects of the problem in the short term. >=20 > Saturday March 17th, RRG -- > http://www1.tools.ietf.org/group/irtf/trac/wiki/RRG >=20 > This is a research group discussion on rechartering the RRG to > look at new architectural approaches (including clean slate=20 > designs). >=20 > Comments and suggestions appreciated. >=20 > Jari, Mark, and Ross >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 05 17:16: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 1HOLTJ-0002xr-39; Mon, 05 Mar 2007 17:15:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOLTH-0002wC-Fj for ram@iab.org; Mon, 05 Mar 2007 17:15:55 -0500 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOLT9-0005Vn-O7 for ram@iab.org; Mon, 05 Mar 2007 17:15:55 -0500 Received: from vaioz1.apnic.net (dhcp21.dhcp.telstra.net [203.50.30.243]) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l25MFfuE041139; Tue, 6 Mar 2007 09:15:42 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070306091137.013b4648@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 06 Mar 2007 09:16:01 +1100 To: Brian E Carpenter , Pekka Nikander From: Geoff Huston Subject: Re: [RAM] PASH: Another SHIM6 proxying draft, in addition to pshim6 In-Reply-To: <45EC406E.1060901@zurich.ibm.com> References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> <0B6CD3B7-0B90-4E9F-AEC0-55E417865F2E@nomadiclab.com> <45EC406E.1060901@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 >How will pash deal with TCP relays along the path (which >recompute the TCP checksum)? This is an open issue for shim6 >and pshim6. At some point the extended legacy of a small number of demented pieces of middleware simply has to stop. Any intermediary system performing TCP and UDP checksums on packets on the fly is simply generating heat rather then an enlightened state of blissful protection! Adjusting generic end-to-end behaviours for such deranged middleware is, imho, a collective waste of time. So, no I don't see this was an open issue for shim6. Geoff _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 06 03:11: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 1HOUkc-0000Lm-PG; Tue, 06 Mar 2007 03:10:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOUkb-0000Le-4y for ram@iab.org; Tue, 06 Mar 2007 03:10:25 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOUkZ-0002rT-Nh for ram@iab.org; Tue, 06 Mar 2007 03:10:25 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CE3EA212D97; Tue, 6 Mar 2007 10:10:09 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5AB55212D94; Tue, 6 Mar 2007 10:10:09 +0200 (EET) In-Reply-To: <45EC406E.1060901@zurich.ibm.com> References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> <0B6CD3B7-0B90-4E9F-AEC0-55E417865F2E@nomadiclab.com> <45EC406E.1060901@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66E374DD-370B-44C9-9416-33575525F549@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] PASH: Another SHIM6 proxying draft, in addition to pshim6 Date: Tue, 6 Mar 2007 07:47:35 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP 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 > pshim6 finds a need for a DNS ALG. Does pash have the same need? That depends on the deployment scenario. I also talked about this with Marcelo last week, and our conclusion was that if you modify pshim6 to use existing PA addresses instead of new PI space as the identifiers, you can also do shim6 without DNS ALG some other odds and ends. There might also be scenarios where you use some kind of "half-PI" addresses as identifiers, but more work is needed in that space. Marcelo prepared some additional text to pshim6 but I don't know if he managed to post it before yesterday's deadline. More generally, I started analysis of this problem (independent of pshim6) in the generix draft. There are some text in Sections 6.3 and 6.4. That is not much, but perhaps a beginning. > How will pash deal with TCP relays along the path (which recompute > the TCP checksum)? This is an open issue for shim6 and pshim6. That depends on a level of detail to which PASH doesn't directly go (nor does LISP, IIRC). In addition to SHIM6 proxying, PASH also outlines HIP proxying. In the HIP case, you have ESP, and the problem goes away since TCP relays won't see the TCP checksum. Or, if they do see it, due to ESP NULL encryption, they should recognise the ESP header and not touch the TCP header. For SHIM6 proxying, I don't think PASH is any different from PSHIM6 in this respect. PASH just outlines a number of deployment scenarios, each requiring slightly different details, while PSHIM6 focuses only one. So, my tentative conclusion here is that the need for DNS ALG and other such details depends more on the deployment scenario, i.e., the nature of identifiers used, than the underlying id/loc separation mechanism. So, the question is more if we use XXXX 1, 1.5, 2, 3 rather than if XXXX is LISP, PASH, or something else. I'll try to add some text about this to a future version of the ILSE draft. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 06 05:53:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOXH6-0007GB-CE; Tue, 06 Mar 2007 05:52:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOXH4-0007G6-Ns for ram@iab.org; Tue, 06 Mar 2007 05:52:06 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOXH3-0006lR-Bj for ram@iab.org; Tue, 06 Mar 2007 05:52:06 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CBEBA19870F; Tue, 6 Mar 2007 12:52:01 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7A1B119870D; Tue, 6 Mar 2007 12:52:01 +0200 (EET) Message-ID: <45ED47D2.20206@piuha.net> Date: Tue, 06 Mar 2007 12:52:02 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [RAM] routing and addressing meetings in Prague References: <45EC22BA.7050207@piuha.net> In-Reply-To: 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: 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 Vidya, > Could someone please post a list of relevant documents that have already > been written on this topic? > I updated the agenda page with the documents that I knew about. Everyone, please send updates if I missed something. And I know there are a couple of documents & presentations coming up that are not published yet. Here's the link: http://www3.ietf.org/proceedings/07mar/agenda/intarea.txt Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 06 06: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 1HOY7S-00069W-DA; Tue, 06 Mar 2007 06:46:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOY7R-00069R-L4 for ram@iab.org; Tue, 06 Mar 2007 06:46:13 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOY7Q-0002Pt-5S for ram@iab.org; Tue, 06 Mar 2007 06:46:13 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E858D1105C2; Tue, 6 Mar 2007 12:46:10 +0100 (CET) Received: from [163.117.139.242] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.242]) by smtp02.uc3m.es (Postfix) with ESMTP id 33FC4110447; Tue, 6 Mar 2007 12:46:07 +0100 (CET) In-Reply-To: <66E374DD-370B-44C9-9416-33575525F549@nomadiclab.com> References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> <0B6CD3B7-0B90-4E9F-AEC0-55E417865F2E@nomadiclab.com> <45EC406E.1060901@zurich.ibm.com> <66E374DD-370B-44C9-9416-33575525F549@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <99143ddb8f99e159da788aa9dc144f1c@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] PASH: Another SHIM6 proxying draft, in addition to pshim6 Date: Tue, 6 Mar 2007 12:47:57 +0100 To: Pekka Nikander X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 El 06/03/2007, a las 6:47, Pekka Nikander escribi=F3: > So, my tentative conclusion here is that the need for DNS ALG and=20 > other such details depends more on the deployment scenario, i.e., the=20= > nature of identifiers used, than the underlying id/loc separation=20 > mechanism. So, the question is more if we use XXXX 1, 1.5, 2, 3=20 > rather than if XXXX is LISP, PASH, or something else. > exactly If you you want a scenario where: The nodes within the multihomed site only configure a single address=20 that is provider independent. We assume that the provider independent address that is configured in=20 the node cannot be globally routable (since this would bloat the=20 routing tables and so on) This basically imposes the following constraints - If we are considering a situation where a host A in a multihomed site=20= using PI identifiers wants to communicate with another host B in a=20 different multihomed site that is using PI identifiers, then The PI=20 identifier of host B must be returned to host A in a AAAA RR since host=20= A only understand AAAA RR. - If we are considering a legacy host C that is not server by a proxy=20 or LISP router that wants to initiate a communication with host A,=20 then the DNS must returns a routable address of host A in the AAAA RR=20 to host C So the result is that the information returned by the DNS in AAAA RR=20 for hosts behind a Proxy or LISP router (in the 1,5 2 and 3 cases)=20 should be the PI identifier for other hosts behind a proxy and a=20 routable address for legacy hosts not behind a proxy The solution for this seems to require some form of DNS ALG as long as=20= hosts don't support a new EID RR AFAICT Regards, marcelo > I'll try to add some text about this to a future version of the ILSE=20= > draft. > > --Pekka Nikander > > > _______________________________________________ > 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 Mar 06 07:09:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOYSm-0000Ww-Cr; Tue, 06 Mar 2007 07:08:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOYSj-0000IJ-Cd for ram@iab.org; Tue, 06 Mar 2007 07:08:13 -0500 Received: from mtagate7.uk.ibm.com ([195.212.29.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOYMV-0005tL-M6 for ram@iab.org; Tue, 06 Mar 2007 07:01:52 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate7.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l26C124Z136776 for ; Tue, 6 Mar 2007 12:01:02 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l26C11151396932 for ; Tue, 6 Mar 2007 12:01:02 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l26C11cx014837 for ; Tue, 6 Mar 2007 12:01:01 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l26C113E014828; Tue, 6 Mar 2007 12:01:01 GMT Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA145602; Tue, 6 Mar 2007 13:00:58 +0100 Message-ID: <45ED57FA.7000906@zurich.ibm.com> Date: Tue, 06 Mar 2007 13:00:58 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [RAM] routing and addressing meetings in Prague References: <45EC22BA.7050207@piuha.net> <45ED47D2.20206@piuha.net> In-Reply-To: <45ED47D2.20206@piuha.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 2007-03-06 11:52, Jari Arkko wrote: > Vidya, > >> Could someone please post a list of relevant documents that have already >> been written on this topic? >> > > I updated the agenda page with the documents that I knew > about. Everyone, please send updates if I missed something. > And I know there are a couple of documents & presentations > coming up that are not published yet. > > Here's the link: > http://www3.ietf.org/proceedings/07mar/agenda/intarea.txt > I believe that RFC 4218, the multi6 threat analysis, is of interest beyond the pure multihoming context. Although old, I think the 8+8/GSE/ESD drafts are still of some active interest: http://tools.ietf.org/id/draft-odell-8+8-00.txt http://tools.ietf.org/id/draft-ietf-ipngwg-gseaddr-00.txt http://tools.ietf.org/id/draft-ietf-ipngwg-esd-analysis-05.txt People with a real historical interest can look at http://www.sobco.com/ipng/archive/index.html, and if anyone has soft copies of any of the drafts listed there without URLs, that would be interesting. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 06 08:17: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 1HOZW7-0002nI-SK; Tue, 06 Mar 2007 08:15:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOZW6-0002nD-1o for ram@iab.org; Tue, 06 Mar 2007 08:15:46 -0500 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOZW1-0000s1-MO for ram@iab.org; Tue, 06 Mar 2007 08:15:46 -0500 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 CFA2A14B3B; Tue, 6 Mar 2007 14:15:26 +0100 (CET) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 06 Mar 2007 14:15:32 +0100 To: Brian E Carpenter ,Jari Arkko From: JFC Morfin Subject: Re: [RAM] routing and addressing meetings in Prague In-Reply-To: <45ED57FA.7000906@zurich.ibm.com> References: <45EC22BA.7050207@piuha.net> <45ED47D2.20206@piuha.net> <45ED57FA.7000906@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070306131526.CFA2A14B3B@smtp7-g19.free.fr> X-Spam-Score: 0.1 (/) 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 Dear Brian and Jari, Thank you for this information and links. However, perusing them quickly I feel there is no analysis or research carried on the user's locator needs. This would be rather worrying because the first question is "identifier-locator split or multi-level locator" while simple user needs like plug and play call for more than identifier-locator split, and sophisticated ones as what I consider (DDDS, interlinked registries, ONES [OPES networking]), could probably be drastically simplified by user's multi-level locators. This is IMHO important because, if we want this study to result into a successful and quick deployment, we have to make sure that the users and the ISPs interests do converge this time (cf. IPv6). jfc At 13:00 06/03/2007, Brian E Carpenter wrote: >Content-Transfer-Encoding: 7bit >On 2007-03-06 11:52, Jari Arkko wrote: >>>Could someone please post a list of relevant documents that have already >>>been written on this topic? >>I updated the agenda page with the documents that I knew >>about. Everyone, please send updates if I missed something. >>And I know there are a couple of documents & presentations >>coming up that are not published yet. >>Here's the link: >>http://www3.ietf.org/proceedings/07mar/agenda/intarea.txt > >I believe that RFC 4218, the multi6 threat analysis, is >of interest beyond the pure multihoming context. > >Although old, I think the 8+8/GSE/ESD drafts are still of >some active interest: > >http://tools.ietf.org/id/draft-odell-8+8-00.txt >http://tools.ietf.org/id/draft-ietf-ipngwg-gseaddr-00.txt >http://tools.ietf.org/id/draft-ietf-ipngwg-esd-analysis-05.txt > >People with a real historical interest can look at >http://www.sobco.com/ipng/archive/index.html, >and if anyone has soft copies of any of the drafts >listed there without URLs, that would be interesting. > > Brian >_______________________________________________ >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 Mar 06 09: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 1HOaWu-00025X-2o; Tue, 06 Mar 2007 09:20:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOaWs-00025P-Vh for ram@iab.org; Tue, 06 Mar 2007 09:20:38 -0500 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOaWe-0003Pm-FB for ram@iab.org; Tue, 06 Mar 2007 09:20:38 -0500 Received: from olvera02 by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50002417372.msg for ; Tue, 06 Mar 2007 15:16:49 +0100 From: "Cesar Olvera" To: "'Jari Arkko'" References: <45EC22BA.7050207@piuha.net> <45ED47D2.20206@piuha.net> <45ED57FA.7000906@zurich.ibm.com> Subject: RE: [RAM] routing and addressing meetings in Prague Date: Tue, 6 Mar 2007 15:18:53 +0100 Message-ID: <005001c75ffa$5f123540$0201a8c0@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45ED57FA.7000906@zurich.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: Acdf5//566tE3LjtSq+meswbvB9ZtgAEhDkQ X-Authenticated-Sender: cesar.olvera@consulintel.es X-HashCash: 1:20:070306:ram@iab.org::Xli0KrrrWdeJEK5e:0000001jjN X-MDRemoteIP: 62.15.238.222 X-Return-Path: cesar.olvera@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 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Tue, 06 Mar 2007 15:16:50 +0100 X-MDAV-Processed: consulintel.es, Tue, 06 Mar 2007 15:16:50 +0100 X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cesar.olvera@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 Brian, I will send you the details of the missing soft copies of IETF IPng effort. Regards, C=E9sar Olvera =20 > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Tuesday, March 06, 2007 1:01 PM > To: Jari Arkko > Cc: ram@iab.org > Subject: Re: [RAM] routing and addressing meetings in Prague >=20 > On 2007-03-06 11:52, Jari Arkko wrote: > > Vidya, > >=20 > >> Could someone please post a list of relevant documents that have=20 > >> already been written on this topic? > >> =20 > >=20 > > I updated the agenda page with the documents that I knew about.=20 > > Everyone, please send updates if I missed something. > > And I know there are a couple of documents & presentations=20 > coming up=20 > > that are not published yet. > >=20 > > Here's the link: > > http://www3.ietf.org/proceedings/07mar/agenda/intarea.txt > >=20 >=20 > I believe that RFC 4218, the multi6 threat analysis, is of=20 > interest beyond the pure multihoming context. >=20 > Although old, I think the 8+8/GSE/ESD drafts are still of=20 > some active interest: >=20 > http://tools.ietf.org/id/draft-odell-8+8-00.txt > http://tools.ietf.org/id/draft-ietf-ipngwg-gseaddr-00.txt > http://tools.ietf.org/id/draft-ietf-ipngwg-esd-analysis-05.txt >=20 > People with a real historical interest can look at=20 > http://www.sobco.com/ipng/archive/index.html, > and if anyone has soft copies of any of the drafts listed=20 > there without URLs, that would be interesting. >=20 > Brian >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 ********************************************** 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 From ram-bounces@iab.org Wed Mar 07 04:09: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 1HOs8i-0005Mo-Nc; Wed, 07 Mar 2007 04:08:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOmbx-00019Y-RT for ram@iab.org; Tue, 06 Mar 2007 22:14:41 -0500 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOmbw-0008Bb-Fn for ram@iab.org; Tue, 06 Mar 2007 22:14:41 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id l273EV591567; Tue, 6 Mar 2007 19:14:35 -0800 (PST) (envelope-from rcallon@juniper.net) Received: from rcallon-lt1.juniper.net ([172.23.1.177]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l273EKB42894; Tue, 6 Mar 2007 19:14:25 -0800 (PST) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070306221232.0398a380@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 06 Mar 2007 22:13:26 -0500 To: Jari Arkko , ram@iab.org From: Ross Callon Subject: Re: [RAM] routing and addressing meetings in Prague In-Reply-To: <45EC22BA.7050207@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 At 04:01 PM 3/5/2007 +0200, Jari Arkko wrote: >... >Thursday 1300-1500, RTGAREA -- (no agenda available yet) > > This meeting focuses on what we could do with BGP to address > some aspects of the problem in the short term. The routing area agenda has been posted at: http://www3.ietf.org/proceedings/07mar/agenda/rtgarea.txt _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 07 04:35: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 1HOsYO-00053Z-18; Wed, 07 Mar 2007 04:35:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsYN-000538-3Y for ram@iab.org; Wed, 07 Mar 2007 04:35:23 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOsYJ-000100-Gw for ram@iab.org; Wed, 07 Mar 2007 04:35:23 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7606016E8E8 for ; Wed, 7 Mar 2007 10:35:18 +0100 (CET) Received: from [163.117.139.242] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.242]) by smtp01.uc3m.es (Postfix) with ESMTP id 244B716E88B for ; Wed, 7 Mar 2007 10:35:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v624) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: marcelo bagnulo braun Date: Wed, 7 Mar 2007 10:37:08 +0100 X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [RAM] Fwd: I-D ACTION:draft-bagnulo-pshim6-01.txt 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 A new version of the P-shim6 draft including some clarifying comments made in the list Regards, marcelo Inicio mensaje reenviado: > De: Internet-Drafts@ietf.org > Fecha: 6 de marzo de 2007 00:50:02 GMT+01:00 > Para: i-d-announce@ietf.org > Cc: Asunto: I-D ACTION:draft-bagnulo-pshim6-01.txt > Responder a: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Proxy Shim6 (P-Shim6) > Author(s) : M. Bagnulo, et al. > Filename : draft-bagnulo-pshim6-01.txt > Pages : 25 > Date : 2007-3-5 > > This draft discusses extensions to the shim6 architecture to support > shim6 proxies that would allow the provision of the following > capabilities: > o Provide Upper Layer Identifier portability. > o Provide Traffic Engineering policy enforcement. > o Off-load of the shim6 context management from the actual peers of > the communication. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bagnulo-pshim6-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-bagnulo-pshim6-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-bagnulo-pshim6-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-3-5153859.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 07 04:36: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 1HOsZL-0005f9-TM; Wed, 07 Mar 2007 04:36:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsZJ-0005eo-P0 for ram@iab.org; Wed, 07 Mar 2007 04:36:21 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOsZI-00019K-8H for ram@iab.org; Wed, 07 Mar 2007 04:36:21 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1D6CB16E8FE for ; Wed, 7 Mar 2007 10:36:19 +0100 (CET) Received: from [163.117.139.242] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.242]) by smtp01.uc3m.es (Postfix) with ESMTP id E399516E8C4 for ; Wed, 7 Mar 2007 10:36:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v624) Content-Transfer-Encoding: 7bit Message-Id: <5b966aee01473d0ce4b0256cd3f46fb2@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: marcelo bagnulo braun Date: Wed, 7 Mar 2007 10:38:08 +0100 X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [RAM] Fwd: I-D ACTION:draft-bagnulo-lisp-threat-00.txt 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 The LISP threat analysis is available in the ID repository Regards, marcelo Inicio mensaje reenviado: > De: Internet-Drafts@ietf.org > Fecha: 6 de marzo de 2007 00:50:02 GMT+01:00 > Para: i-d-announce@ietf.org > Cc: Asunto: I-D ACTION:draft-bagnulo-lisp-threat-00.txt > Responder a: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Preliminary LISP Threat Analysis > Author(s) : M. Bagnulo > Filename : draft-bagnulo-lisp-threat-00.txt > Pages : 10 > Date : 2007-3-5 > > This document performs a preliminary threat analysis on the > Locator/ID Separation Protocol (LISP) as defined in draft- > farinacci- > lisp-00.txt. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bagnulo-lisp-threat-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-bagnulo-lisp-threat-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-bagnulo-lisp-threat-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-3-5160902.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 07 20:11: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 1HP79j-0003Xn-Ku; Wed, 07 Mar 2007 20:10:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP79h-0003XQ-Qu for ram@iab.org; Wed, 07 Mar 2007 20:10:53 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP79d-0002TS-8x for ram@iab.org; Wed, 07 Mar 2007 20:10:53 -0500 Received: from [220.227.179.150] (account marshall_eubanks HELO [192.168.100.16]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 6283442; Wed, 07 Mar 2007 20:10:48 -0500 In-Reply-To: <45EC22BA.7050207@piuha.net> References: <45EC22BA.7050207@piuha.net> 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] routing and addressing meetings in Prague Date: Wed, 7 Mar 2007 20:10:41 -0500 To: Jari Arkko X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Should the Friday RTWG be on this list ? Congress III RTG rtgwg Routing Area Working Group WG Regards Marshall On Mar 5, 2007, at 9:01 AM, Jari Arkko wrote: > Hi all, > > We are planning to talk about the routing and addressing > topic in Prague in a number of different meetings. > > Wednesday 1830-1930, Plenary -- > http://www.arkko.com/ietf/ietf-68/ietf68_roap_agenda.txt > > This is a short report on where we are with this problem and what > aspects of it the IETF can address. > > Thursday 0900-1130, INTAREA -- > http://www3.ietf.org/proceedings/07mar/agenda/intarea.txt > > This is an architectural discussion about future IETF work on > identifier-locator split and multi-level locator designs that > may help > issues with routing scalability and other issues in the long term. > > Thursday 1300-1500, RTGAREA -- (no agenda available yet) > > This meeting focuses on what we could do with BGP to address > some aspects of the problem in the short term. > > Saturday March 17th, RRG -- > http://www1.tools.ietf.org/group/irtf/trac/wiki/RRG > > This is a research group discussion on rechartering the RRG to > look at new architectural approaches (including clean slate > designs). > > Comments and suggestions appreciated. > > Jari, Mark, and Ross > > > _______________________________________________ > 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 Mar 07 20:57: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 1HP7rl-0008CN-3t; Wed, 07 Mar 2007 20:56:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP7rj-0008AE-Rc for ram@ietf.org; Wed, 07 Mar 2007 20:56:23 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP7ri-0001LN-Ez for ram@ietf.org; Wed, 07 Mar 2007 20:56:23 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 07 Mar 2007 17:56:18 -0800 X-IronPort-AV: i="4.14,262,1170662400"; d="scan'208"; a="119023781:sNHT45761724" 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 l281uHit030617; Wed, 7 Mar 2007 17:56:17 -0800 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 l281uBxR028777; Thu, 8 Mar 2007 01:56:11 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, 7 Mar 2007 17:56:11 -0800 Received: from [192.168.0.4] ([10.21.112.206]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 17:56:10 -0800 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: <36908560-2B84-4F93-AD39-257F75096F5B@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Pre-draft: mapper protocol Date: Wed, 7 Mar 2007 17:56:16 -0800 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 Mar 2007 01:56:10.0716 (UTC) FILETIME=[F1D259C0:01C76124] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1482; t=1173318977; x=1174182977; c=relaxed/simple; s=sjdkim7002; 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]=20Pre-draft=3A=20mapper=20protocol |Sender:=20; bh=WWWfrMRxB7JsaET8eSdeNWAms2mgS/4dMO/FTkTn2Lo=; b=fM01gdWHzgGkGy+u6kCMoUHymVLjn325KuC2yuty4T+1OLFBQu16pt7UQ3gpj7Ut8M2hfgP8 lZ8cBwsuXiUH7IdkSCbcDpaZnTEimDZnLVnSiVa524Gg7zGfI5AoOgYl; Authentication-Results: sj-dkim-7; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ram@ietf.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 > Since draft submission is now closed but I want to get this out > before the IETF meeting, I decided to write a short "pre-draft". No > boilerplate or much in the way of formatting yet. You can find it > at http://www.muada.com/drafts/draft-van-beijnum-mapper-00.txt So, Iljitsch, you basically reinvented LISP here with one difference. The difference is that there is a third-party involved in doing the mapping service versus the decapsulation device telling the encapsulation device directly. I did assume from your draft that you won't have routable-IDs. So if this is true, what does the encapsulation device do with packets when it doesn't have the mapping? That is, it gets a packet for which it does not have an EID-to-RLOC mapping, so it makes the request to the server over a TCP connection. While the encapsulation device is waiting for the reply, is it dropping packets on the floor? This is why we have LISP 1 and 1.5, we don't want to drop packets. So if you want mapping on-demand, you have to route the EID. If you don't want to route the EID and you don't want to drop packets, you either have to push the mappings everywhere or you intercept packets the host uses to setup connections (like DNS-snooping). Tough choices. The best part of your proposal is that you can authenticate the mappings. But once you buy into a third-party you can have all sorts of security tools at your disposal. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 07 21:05: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 1HP7zp-0003w6-Ja; Wed, 07 Mar 2007 21:04:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP7zo-0003w1-5q for ram@iab.org; Wed, 07 Mar 2007 21:04:44 -0500 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP7zl-0002OP-Ov for ram@iab.org; Wed, 07 Mar 2007 21:04:44 -0500 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 3091853E0F8; Wed, 7 Mar 2007 21:04:39 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id YNyEad0GOpxy; Wed, 7 Mar 2007 21:04:31 -0500 (EST) Received: from [172.16.13.202] (dsl093-003-111.det1.dsl.speakeasy.net [66.93.3.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 7A2F353E0EA; Wed, 7 Mar 2007 21:04:30 -0500 (EST) In-Reply-To: References: <45EC22BA.7050207@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1173CD1C-8E03-4477-8E4C-1FA667289607@bgp.nu> Content-Transfer-Encoding: 7bit From: "John G. Scudder" Subject: Re: [RAM] routing and addressing meetings in Prague Date: Wed, 7 Mar 2007 21:04:20 -0500 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 don't see why it should. So far we have a pretty light agenda for rtgwg. Perhaps you are conflating rtgwg and rtg-area? --John On Mar 7, 2007, at 8:10 PM, Marshall Eubanks wrote: > Should the Friday RTWG be on this list ? > > Congress III RTG rtgwg Routing Area Working Group WG > > Regards > Marshall > > On Mar 5, 2007, at 9:01 AM, Jari Arkko wrote: > >> Hi all, >> >> We are planning to talk about the routing and addressing >> topic in Prague in a number of different meetings. >> >> Wednesday 1830-1930, Plenary -- >> http://www.arkko.com/ietf/ietf-68/ietf68_roap_agenda.txt >> >> This is a short report on where we are with this problem and what >> aspects of it the IETF can address. >> >> Thursday 0900-1130, INTAREA -- >> http://www3.ietf.org/proceedings/07mar/agenda/intarea.txt >> >> This is an architectural discussion about future IETF work on >> identifier-locator split and multi-level locator designs that >> may help >> issues with routing scalability and other issues in the long term. >> >> Thursday 1300-1500, RTGAREA -- (no agenda available yet) >> >> This meeting focuses on what we could do with BGP to address >> some aspects of the problem in the short term. >> >> Saturday March 17th, RRG -- >> http://www1.tools.ietf.org/group/irtf/trac/wiki/RRG >> >> This is a research group discussion on rechartering the RRG to >> look at new architectural approaches (including clean slate >> designs). >> >> Comments and suggestions appreciated. >> >> Jari, Mark, and Ross >> >> >> _______________________________________________ >> 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 > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 07 21:13: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 1HP87P-0007Ip-1C; Wed, 07 Mar 2007 21:12:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP87M-00070v-V1 for ram@iab.org; Wed, 07 Mar 2007 21:12:32 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP87L-0002pz-Ih for ram@iab.org; Wed, 07 Mar 2007 21:12:32 -0500 Received: from [220.227.179.150] (account marshall_eubanks HELO [192.168.100.16]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 6283566; Wed, 07 Mar 2007 21:12:31 -0500 In-Reply-To: <1173CD1C-8E03-4477-8E4C-1FA667289607@bgp.nu> References: <45EC22BA.7050207@piuha.net> <1173CD1C-8E03-4477-8E4C-1FA667289607@bgp.nu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <41DACBB6-FF0D-49AA-8C5A-8EE13A6D3718@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [RAM] routing and addressing meetings in Prague Date: Wed, 7 Mar 2007 21:12:23 -0500 To: "John G. Scudder" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Mar 7, 2007, at 9:04 PM, John G. Scudder wrote: > I don't see why it should. That's what I wanted to know. > So far we have a pretty light agenda for rtgwg. Perhaps you are > conflating rtgwg and rtg-area? > > --John > > On Mar 7, 2007, at 8:10 PM, Marshall Eubanks wrote: > >> Should the Friday RTWG be on this list ? >> >> Congress III RTG rtgwg Routing Area Working Group WG >> >> Regards >> Marshall >> >> On Mar 5, 2007, at 9:01 AM, Jari Arkko wrote: >> >>> Hi all, >>> >>> We are planning to talk about the routing and addressing >>> topic in Prague in a number of different meetings. >>> >>> Wednesday 1830-1930, Plenary -- >>> http://www.arkko.com/ietf/ietf-68/ietf68_roap_agenda.txt >>> >>> This is a short report on where we are with this problem and what >>> aspects of it the IETF can address. >>> >>> Thursday 0900-1130, INTAREA -- >>> http://www3.ietf.org/proceedings/07mar/agenda/intarea.txt >>> >>> This is an architectural discussion about future IETF work on >>> identifier-locator split and multi-level locator designs that >>> may help >>> issues with routing scalability and other issues in the long >>> term. >>> >>> Thursday 1300-1500, RTGAREA -- (no agenda available yet) >>> >>> This meeting focuses on what we could do with BGP to address >>> some aspects of the problem in the short term. >>> >>> Saturday March 17th, RRG -- >>> http://www1.tools.ietf.org/group/irtf/trac/wiki/RRG >>> >>> This is a research group discussion on rechartering the RRG to >>> look at new architectural approaches (including clean slate >>> designs). >>> >>> Comments and suggestions appreciated. >>> >>> Jari, Mark, and Ross >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 09 06:57: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 1HPdhY-0001Xt-8Z; Fri, 09 Mar 2007 06:56:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPdhW-0001La-J7 for ram@ietf.org; Fri, 09 Mar 2007 06:55:58 -0500 Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPdhU-0004Hs-Us for ram@ietf.org; Fri, 09 Mar 2007 06:55:58 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [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 l29BtLwB060976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Mar 2007 12:55:22 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <36908560-2B84-4F93-AD39-257F75096F5B@cisco.com> References: <36908560-2B84-4F93-AD39-257F75096F5B@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Pre-draft: mapper protocol Date: Fri, 9 Mar 2007 12:55:31 +0100 To: Dino Farinacci X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.2 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: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ram@ietf.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 8-mrt-2007, at 2:56, Dino Farinacci wrote: >> Since draft submission is now closed but I want to get this out >> before the IETF meeting, I decided to write a short "pre-draft". >> No boilerplate or much in the way of formatting yet. You can find >> it at http://www.muada.com/drafts/draft-van-beijnum-mapper-00.txt > So, Iljitsch, you basically reinvented LISP here with one difference. The difference is the mapping service. This is important. > The difference is that there is a third-party involved in doing the > mapping service versus the decapsulation device telling the > encapsulation device directly. Yes, this is a bit like the TLD system in the DNS (although there is no equivalent of the root servers) which helps parallelism because you know where to find authoritative information for a specific part of the identifier space. > I did assume from your draft that you won't have routable-IDs. So > if this is true, what does the encapsulation device do with packets > when it doesn't have the mapping? Identifiers are just PI prefixes, so what happens is the same thing that happens today if the destination isn't in the routing tables: packet is dropped with a !N. The idea is that every prefix is either in the regular BGP table like today, or it is in the mapping system. This can be a local decision, i.e., an AS can decide to run this system locally, encapsulating packets with the 90% destination prefixes that attract 10% of the traffic right at the edge, and decapsulating them again next to the border to the next hop AS. That way, the core routers don't need to carry a full table but no cooperation with external ASes is required. > That is, it gets a packet for which it does not have an EID-to-RLOC > mapping, so it makes the request to the server over a TCP > connection. While the encapsulation device is waiting for the > reply, is it dropping packets on the floor? Right. Originally, I wanted to make a flooding-only system, but I think having the option to work on-demand can be useful in certain cases, although then you have this problem. The case where it can be useful is if both the ISP and the source end-user have encapsulation devices, so at the source it's possible to dump the packets at the ISP and they're delivered, but if they obtain the mapping info they can do all of this themselves and make smarter traffic engineering decisions etc. The ISP would have the mapping state flooded to its encapsulation devices, while the end-user would work on-demand. > The best part of your proposal is that you can authenticate the > mappings. But once you buy into a third-party you can have all > sorts of security tools at your disposal. :-) Iljitsch _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 09 15:07: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 1HPlM1-0003uI-CB; Fri, 09 Mar 2007 15:06:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPlM0-0003tx-EY for ram@ietf.org; Fri, 09 Mar 2007 15:06:16 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPlLz-0001M9-4k for ram@ietf.org; Fri, 09 Mar 2007 15:06:16 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2007 12:06:15 -0800 X-IronPort-AV: i="4.14,268,1170662400"; d="scan'208"; a="399397986:sNHT46712748" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l29K6EqZ024097; Fri, 9 Mar 2007 12:06:14 -0800 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 l29K6ExR021112; Fri, 9 Mar 2007 20:06:14 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); Fri, 9 Mar 2007 12:06:13 -0800 Received: from [192.168.0.4] ([10.21.123.79]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 12:06:13 -0800 In-Reply-To: References: <36908560-2B84-4F93-AD39-257F75096F5B@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <982CFE55-67A2-49DC-A746-7C708E6AAA37@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Pre-draft: mapper protocol Date: Fri, 9 Mar 2007 12:06:18 -0800 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Mar 2007 20:06:13.0337 (UTC) FILETIME=[633C1490:01C76286] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1117; t=1173470774; x=1174334774; 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]=20Pre-draft=3A=20mapper=20protocol |Sender:=20; bh=qcQmqdYe6qdZpTyyQqztN8jm/UBHDM/gXgMrT3VwEcI=; b=qfH442Joj4O38728sYUMmafVYwu2ij40J1SsmljUlJ8xNTETnnUSGANeKWM3Q74c5cPmCDDc q8+xKp8qYmPS2Eh2QgP6P1bSfWntR9e+ZNQGqRajo1m7VbgPJnK3fEfP; 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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ram@ietf.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 > The idea is that every prefix is either in the regular BGP table > like today, or it is in the mapping system. This can be a local > decision, i.e., an AS can decide to run this system locally, > encapsulating packets with the 90% destination prefixes that > attract 10% of the traffic right at the edge, and decapsulating > them again next to the border to the next hop AS. That way, the > core routers don't need to carry a full table but no cooperation > with external ASes is required. This is what we defined in LISP as re-encapsulating versus recursive tunneling. >> That is, it gets a packet for which it does not have an EID-to- >> RLOC mapping, so it makes the request to the server over a TCP >> connection. While the encapsulation device is waiting for the >> reply, is it dropping packets on the floor? > > Right. Originally, I wanted to make a flooding-only system, but I > think having the Don't you think dropping packets is a non-starter? Or are you saying the expense of dropping packets is for the benefit of using non- routable PI IDs? Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 11 14:14: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 1HQSWu-0000pU-Ko; Sun, 11 Mar 2007 14:12:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQSWs-0000pM-P1 for ram@ietf.org; Sun, 11 Mar 2007 14:12:22 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQSWn-0004UL-NQ for ram@ietf.org; Sun, 11 Mar 2007 14:12:22 -0400 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [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 l2BIBe0I009986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Mar 2007 19:11:40 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <982CFE55-67A2-49DC-A746-7C708E6AAA37@cisco.com> References: <36908560-2B84-4F93-AD39-257F75096F5B@cisco.com> <982CFE55-67A2-49DC-A746-7C708E6AAA37@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Pre-draft: mapper protocol Date: Sun, 11 Mar 2007 19:11:26 +0100 To: Dino Farinacci X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 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: d6b246023072368de71562c0ab503126 Cc: ram@ietf.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 9-mrt-2007, at 21:06, Dino Farinacci wrote: >>> That is, it gets a packet for which it does not have an EID-to- >>> RLOC mapping, so it makes the request to the server over a TCP >>> connection. While the encapsulation device is waiting for the >>> reply, is it dropping packets on the floor? >> Right. Originally, I wanted to make a flooding-only system, but I >> think having the > Don't you think dropping packets is a non-starter? Or are you > saying the expense of dropping packets is for the benefit of using > non-routable PI IDs? I don't envision any real-world use cases where packets would be dropped, even though it's certainly possible that someone could create one, just like with existing IP the idea is to make a best effort to deliver the packets but if you misconfigure a few or even a lot of dropped packets are possible. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 11 14:21: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 1HQSg4-0003lv-UY; Sun, 11 Mar 2007 14:21:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQSg4-0003ln-IZ for ram@ietf.org; Sun, 11 Mar 2007 14:21:52 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQSg1-0005ei-8g for ram@ietf.org; Sun, 11 Mar 2007 14:21:52 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 11 Mar 2007 11:21:48 -0700 X-IronPort-AV: i="4.14,271,1170662400"; d="scan'208"; a="47367945:sNHT290967336" 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 l2BILmB7023280; Sun, 11 Mar 2007 11:21:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2BILkdv015084; Sun, 11 Mar 2007 18:21:46 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); Sun, 11 Mar 2007 11:21:45 -0700 Received: from [192.168.0.4] ([10.21.66.181]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 11:21:45 -0700 In-Reply-To: References: <36908560-2B84-4F93-AD39-257F75096F5B@cisco.com> <982CFE55-67A2-49DC-A746-7C708E6AAA37@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2D00AA43-FE6D-4D0D-BDC7-27C6BEC40EED@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Pre-draft: mapper protocol Date: Sun, 11 Mar 2007 11:21:45 -0700 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Mar 2007 18:21:45.0610 (UTC) FILETIME=[203456A0:01C7640A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=617; t=1173637308; x=1174501308; 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]=20Pre-draft=3A=20mapper=20protocol |Sender:=20; bh=EBtOc7DHcpYEfXxuc+TEysfKtQteeHZ2hpQm55fzOTU=; b=GSPR0os2ifiewDg7ms+lzgMF9pzvk5EW3K9KS8afckxLb1EDA7i5O6xeKQsTNe0Z9bOmAohX AQokJQM9fzl/h7sPoSsgjJg1YuGkk5KfeOxBDAUDG/LvAXCBQojQOHlC; 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: 08170828343bcf1325e4a0fb4584481c Cc: ram@ietf.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 don't envision any real-world use cases where packets would be > dropped, even though it's certainly possible that someone could > create one, just like with existing IP the idea is to make a best > effort to deliver the packets but if you misconfigure a few or even > a lot of dropped packets are possible. Are you saying that there will always be a mapping available at the encapsulating router? Can you answer my question directly. I will repeat it: What happens when a packet comes to an encapsulating router and there is no mapping for the ID? What happens to the packet? Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 11 14:31:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQSp0-0001nA-3h; Sun, 11 Mar 2007 14:31:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQSoy-0001ld-Ik for ram@ietf.org; Sun, 11 Mar 2007 14:31:04 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQSoy-0006su-7B for ram@ietf.org; Sun, 11 Mar 2007 14:31:04 -0400 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [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 l2BIUiS3010254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Mar 2007 19:30:44 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <2D00AA43-FE6D-4D0D-BDC7-27C6BEC40EED@cisco.com> References: <36908560-2B84-4F93-AD39-257F75096F5B@cisco.com> <982CFE55-67A2-49DC-A746-7C708E6AAA37@cisco.com> <2D00AA43-FE6D-4D0D-BDC7-27C6BEC40EED@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A17482F-AA73-403D-9EC8-B23EA838D016@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Pre-draft: mapper protocol Date: Sun, 11 Mar 2007 19:30:58 +0100 To: Dino Farinacci X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.0 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: 2409bba43e9c8d580670fda8b695204a Cc: ram@ietf.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 11-mrt-2007, at 19:21, Dino Farinacci wrote: >> I don't envision any real-world use cases where packets would be >> dropped, even though it's certainly possible that someone could >> create one, just like with existing IP the idea is to make a best >> effort to deliver the packets but if you misconfigure a few or >> even a lot of dropped packets are possible. > Are you saying that there will always be a mapping available at the > encapsulating router? When do engineers ever use the word "always"? > Can you answer my question directly. I will repeat it: > What happens when a packet comes to an encapsulating router and > there is no mapping for the ID? What happens to the packet? The exact same thing that happens when any packet enters any router that doesn't have a route for the packet's destination: it gets dropped. Why would that be worthy of having an email exchange over? You should only run the encap/mapping service in on-demand mode when there are either regular routers or another encap/mapping service further upstream that can handle the packets that are generated before there is a mapping in the on-demand encapsulation device. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 12 11:00: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 1HQlzt-0001cI-NQ; Mon, 12 Mar 2007 10:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQlzs-0001bo-7R for ram@iab.org; Mon, 12 Mar 2007 10:59:36 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQlzq-0006Vv-PD for ram@iab.org; Mon, 12 Mar 2007 10:59:36 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l2CExYs5085792 for ; Mon, 12 Mar 2007 14:59:34 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l2CExXd22158812 for ; Mon, 12 Mar 2007 15:59:33 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l2CExX9I030201 for ; Mon, 12 Mar 2007 15:59:33 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l2CExXpi030181 for ; Mon, 12 Mar 2007 15:59:33 +0100 Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA101678 for ; Mon, 12 Mar 2007 15:59:32 +0100 Message-ID: <45F56AD3.8010805@zurich.ibm.com> Date: Mon, 12 Mar 2007 15:59:31 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ram@iab.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [RAM] Re: I-D ACTION:draft-nikander-ram-ilse-00.txt 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 out of time to fully review this (but it's very interesting). A couple of very quick comments though. > 3.3.1. API compatibility ... > Unfortunately, there appears to be a number of important applications > that assume more. Basically, they assume that they can hand the > address (either as a binary blob or encoded as an ascii string) to > any other host and that host will also be able to use the address in > the same way. This is the so called referral problem. Fortunately, > for the present discussion, this property has already been largely > broken by the prevalence of NATs and firewalls, and therefore is not > that important any more than it once was. I have some problems with this text. It seems to imply there is something evil about referrals. However, they are a fundamental necessity of any multi-party application - party A must be able to tell party B how to find party C. Since the whole beauty of the Internet is this ability, the issue is not the requirement. From 1981 through about 1994 (RFC 1631) IP addresses worked just fine for this. So it isn't "fortunate" that this property has been broken. It's actually tragic that it's been *unpredictably* broken; sometimes it works and sometimes it doesn't. The conclusion is nothing to do with the socket API, IMHO. The conclusion is that we *must* design a new namespace to fix this breakage. Today everybody implementing a multiparty application has to solve this problem again. > 3.3.2. Host-Router interface > > TBD: This section needs to be written. When you write it, please cover TCP/IP and IPSec offload, RDMA (RFC 4296/4297), and virtual IP addressing in server clusters. Not all "host" functions are implemented in hosts. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 12 12:10: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 1HQn58-0005J5-Ic; Mon, 12 Mar 2007 12:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQn57-0005Iz-GX for ram@iab.org; Mon, 12 Mar 2007 12:09:05 -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 1HQn4z-0004ET-G4 for ram@iab.org; Mon, 12 Mar 2007 12:09:05 -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 l2CG8ufg007315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Mar 2007 11:08:56 -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 l2CG8tfH005627; Mon, 12 Mar 2007 09:08:55 -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 l2CG8tLj005618; Mon, 12 Mar 2007 09:08:55 -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); Mon, 12 Mar 2007 09:08:55 -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] routing and addressing meetings in Prague Date: Mon, 12 Mar 2007 09:08:55 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774796@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <45ED47D2.20206@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] routing and addressing meetings in Prague Thread-Index: Acdf3ZjKnliJD1ZFTM+4qgnXGZEBvQE4rfkg References: <45EC22BA.7050207@piuha.net> <45ED47D2.20206@piuha.net> From: "Templin, Fred L" To: "Jari Arkko" X-OriginalArrivalTime: 12 Mar 2007 16:08:55.0783 (UTC) FILETIME=[BC3AFF70:01C764C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Jari, On the agenda page under "RECENT SOLUTIONS", please add: [IPVLX] Multiple drafts, see http://ipvlx.org Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Tuesday, March 06, 2007 2:52 AM > To: Narayanan, Vidya > Cc: ram@iab.org > Subject: Re: [RAM] routing and addressing meetings in Prague >=20 > Vidya, >=20 > > Could someone please post a list of relevant documents that=20 > have already > > been written on this topic?=20 > > =20 >=20 > I updated the agenda page with the documents that I knew > about. Everyone, please send updates if I missed something. > And I know there are a couple of documents & presentations > coming up that are not published yet. >=20 > Here's the link: > http://www3.ietf.org/proceedings/07mar/agenda/intarea.txt >=20 > Jari >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 13 07:37: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 1HR5Hu-0006pH-2x; Tue, 13 Mar 2007 07:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR5Ht-0006pC-45 for ram@iab.org; Tue, 13 Mar 2007 07:35:29 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR5Hq-0000Al-LQ for ram@iab.org; Tue, 13 Mar 2007 07:35:29 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id AAF0F2130CC; Tue, 13 Mar 2007 13:35:20 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6B371212F9F; Tue, 13 Mar 2007 13:35:20 +0200 (EET) In-Reply-To: <45F56AD3.8010805@zurich.ibm.com> References: <45F56AD3.8010805@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <01E450FE-43BA-43DF-99E3-9ED024E1A04C@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] Re: I-D ACTION:draft-nikander-ram-ilse-00.txt Date: Tue, 13 Mar 2007 13:35:18 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 >> 3.3.1. API compatibility > ... >> Unfortunately, there appears to be a number of important >> applications >> that assume more. Basically, they assume that they can hand the >> address (either as a binary blob or encoded as an ascii string) to >> any other host and that host will also be able to use the >> address in >> the same way. This is the so called referral problem. >> Fortunately, >> for the present discussion, this property has already been largely >> broken by the prevalence of NATs and firewalls, and therefore >> is not >> that important any more than it once was. > > I have some problems with this text. It seems to imply there is > something evil about referrals. That is unintentional; sorry for my unfortunate wording. The only "evil" about referrals is that is somewhat hard to implement in certain id/loc separation scenarios, and requires new infrastructure in some others. > However, they are a fundamental necessity of any multi-party > application - party A must be able to tell party B how to find > party C. Since the whole beauty of the Internet is this ability, > the issue is not the requirement. From 1981 through about 1994 (RFC > 1631) IP addresses worked just fine for this. I agree. > So it isn't "fortunate" that this property has been broken. It's > actually > tragic that it's been *unpredictably* broken; sometimes it works and > sometimes it doesn't. I agree. > The conclusion is nothing to do with the socket API, IMHO. The > conclusion > is that we *must* design a new namespace to fix this breakage. Today > everybody implementing a multiparty application has to solve this > problem > again. I agree other than that fixing this breakage is somewhat hard, in the economic sense. Technically I don't see any big problems; there exists enough of research experience on both flat and hierarchical name resolution and id-based routing that we know, in the technical sense, how to provide the required feature. The problem is how to provide it in an economically sustainable way. About the following changed wording: There appears to be a number of important applications that assume more. Basically, they assume that they can hand the address (either as a binary blob or encoded as an ASCII string) to any other host and that host will also be able to use the address in the same way. This is a strict form of the so called referral problem. However, this property has been largely broken by the prevalence of NATs and firewalls, and therefore is not clear of how important it is to preserve it over the compatibility API. More generally, the looser form of the referral problem, where a host hands over something (as opposed to a binary or ASCII compatible address-like string), is clearly something that has to be solved. That is, designing a identifier new name space should allow the hosts once more refer to other hosts (or other objects), through using the new identifiers, in a persistent and location-independent way. However, whether this support should be included to the legacy APIs, and especially to the IPv4 API where referrals between hosts work relatively poorly today, is an issue where one should carefully consider the benefits vs. the added complexity. >> 3.3.2. Host-Router interface >> TBD: This section needs to be written. > > When you write it, please cover TCP/IP and IPSec offload, RDMA > (RFC 4296/4297), and virtual IP addressing in server clusters. > Not all "host" functions are implemented in hosts. Ok, tnx for the tip. I added it to my internal version as a note. --Pekka _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 13 21:17: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 1HRI5T-0000qd-R3; Tue, 13 Mar 2007 21:15:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRI5T-0000qY-5a for ram@ietf.org; Tue, 13 Mar 2007 21:15:31 -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 1HRI5L-0002mz-QR for ram@ietf.org; Tue, 13 Mar 2007 21:15:31 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2E1FLdV016142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 13 Mar 2007 20:15:21 -0500 (CDT) 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 l2E1FKoD025570 for ; Tue, 13 Mar 2007 20:15:20 -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 l2E1FCN4025097 for ; Tue, 13 Mar 2007 20:15:20 -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); Tue, 13 Mar 2007 18:15:19 -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: Tue, 13 Mar 2007 18:15:18 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747A0@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LISP, eFIT and IPvLX Thread-Index: AcddKODcDKLxu0aHTNOb9u+ziDv4UQIpQs0w References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com><60C4A248E730F249990993E3B9BD44D80322B119@xmb-sjc-218.amer.cisco.com><6B864A95-1728-4761-8A58-5ACD3F0BE7DB@cisco.com><8a27c530ddfa3d61ec1fab05812d7ded@it.uc3m.es> From: "Templin, Fred L" To: X-OriginalArrivalTime: 14 Mar 2007 01:15:19.0061 (UTC) FILETIME=[3AFFFC50:01C765D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [RAM] LISP, eFIT and IPvLX 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 Today I finally got the chance to sit down and look at the LISP and eFIT proposals. What the LISP proposal is calling "LISP 2" (and possibly also "LISP 3") is basically the same thing as the IPvLX proposal, which has been around for a few years. LISP 1 and LISP 1.5 use an interesting mechanism for locator/identifer mapping, but they do seem to require that identifiers be routable across a global topology rather than just within the local site which could (perhaps) limit their applicability to near-term only. IPvLX on the other hand separates the user address space from the provider address space by using a mapping service that is separate from the global routing infrastructure, as suggested by eFIT. But also, IPvLX is just the core proposal of a suite of inter-related proposals (see: http://ipvlx.org) that provide building blocks for the future Internet vision such as articulated by eFIT. I could talk more about the other proposals if anyone is interested (which I think they should be, because they apply equally well to LISP and eFIT as they do to IPvLX). But, I'll stop here for now because I don't pretend to have all the answers; only an inkling of a few pieces to the puzzle. I am of course open to comments and questions on IPvLX and its relation to LISP and eFIT also. Thanks - Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 15 09:28: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 1HRpwr-0007va-Ps; Thu, 15 Mar 2007 09:24:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRpwq-0007vV-Em for ram@iab.org; Thu, 15 Mar 2007 09:24:52 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRpwo-00073s-Qm for ram@iab.org; Thu, 15 Mar 2007 09:24:52 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 16142198722 for ; Thu, 15 Mar 2007 15:24:47 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 986A6198720 for ; Thu, 15 Mar 2007 15:24:46 +0200 (EET) Message-ID: <45F94921.7010707@piuha.net> Date: Thu, 15 Mar 2007 15:24:49 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: ram@iab.org 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: c83ccb5cc10e751496398f1233ca9c3a Subject: [RAM] what we should be working on 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 have spent some time thinking on what we should focus on in this space. As you have surely observed, a wide variety of things have been on the table during the discussion, both in terms of the understanding the problem or the scope of the solution. Solution ideas have ranged from small things to what I would classify clean-slate work. My first suggestion is that it makes sense to divide and conquer. I think we have some low-hanging fruit that deserve to picked early, and we some architectural work that will take time to develop and even more to deploy. For instance, looking at some data that Geoff showed me a while ago, it seems that highest BGP update activity is concentrated to a small set of players. Is there something that we can do in BGP to recognize these cases and deal with them in a more efficient manner. I think this is one of the topics that RTGAREA will talk about on Thursday. Another update related issue is that I'm the final IESG blessing away from getting NEMO WG rechartered to produce an efficient scheme for the airline industry's mobility problem. I think this is doable without incurring either a lengthy tunneling delay or a huge BGP impact. There are probably more issues like that in the routing space, low hanging fruit that improves the general performance of the routing system. Hardware development engineers need to do things, too. I have recently convinced myself that significant improvements are possible here (moving to commodity components etc). But this is not something that the IETF is really an expert on, so I don't want to say more about that. But even if we keep engineering the BGP system and improving routers (perhaps even to the point of there not being a problem with the current table growth in the near future), I think it still makes sense to work on architectural changes. Even if we can scale routers to certain size of the Internet at a certain time, if we had more architectural tools in our hands, perhaps we could support a bigger Internet with them, or sooner. Or with more multihoming, traffic engineering, or permanent address space than otherwise possible. I can't get my personal PI space, big companies can -- is that as it should be, or something to be improved upon? But what would be the properties of the solution we are looking for be? So far, we have seen a lot of different ideas. We are planning to spend most of the INTAREA meeting next Thursday to talk about this topic (more than the actual bits). >From my perspective, these boundary conditions should probably be the starting point so that we at least talk about the same space: - Useful for better scaling of the routing system, but also useful for other purposes. Details of this should be explored further. What is usel for the scaling of the routing system, exactly, to begin with? And should the solution be useful for traffic engineering? Mobility? Multihoming? Some new security benefits? - Deployable. In particular, backwards compatible with current devices: o IP looks the same to devices that have not been updated. o Allow existing applications (and APIs) to work unchanged. Should think about referrals, too. o Not rehash old issues; assume IPv4, IPv6, NATs, etc. exist. Focus on what is useful now, given that we are where we are today. No redefinition IPv6. - Goes somehow beyond the solutions we already have. For instance, a lot of people seem to believe we need a network- based approach in addition to (or instead of) a host based approach. Or maybe we need better host based mechanisms. In any case, it is important to realize that we have plenty of tunneling mechanisms, and some identifier-locator split or multi-level identifier designs. - Seriously consider supporting IPv4. I know this may be hard with some of the solutions, so maybe its not achievable. But the current routing table growth problem is in the IPv4 side, and while we could develop an IPv6-only solution, I fear that it would lead to having to develop some other solution for IPv4 later. And if there was no solution for IPv4, I'm not sure we would be have a big impact for real life devices or the use of the Internet, until quite far in the future (maybe 10 years). - There must be deployment incentives that cause people who need to upgrade to actually upgrade. For instance, if the benefits and costs its easier to argue that something should be deployed than if they go to different parties. Thoughts on these? Something to add, or take away? Finally, I hope that the research community (RRG, HIPRG, everyone else) will keep working on designs that go beyond what is presented above, including clean-slate identifier-locator split architectures, new routing paradigms such as compact routing, etc. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 15 10:48:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrEa-0004CA-EK; Thu, 15 Mar 2007 10:47:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrEZ-0004C0-6y for ram@iab.org; Thu, 15 Mar 2007 10:47:15 -0400 Received: from imo-m21.mx.aol.com ([64.12.137.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRrEX-0002wb-UO for ram@iab.org; Thu, 15 Mar 2007 10:47:15 -0400 Received: from HeinerHummel@aol.com by imo-m21.mx.aol.com (mail_out_v38_r7.6.) id b.ce8.ba912b3 (48624); Thu, 15 Mar 2007 10:46:58 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Thu, 15 Mar 2007 10:46:58 EDT Subject: Re: [RAM] what we should be working on To: jari.arkko@piuha.net, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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="===============0070849037==" Errors-To: ram-bounces@iab.org --===============0070849037== Content-Type: multipart/alternative; boundary="-----------------------------1173970018" -------------------------------1173970018 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 15.03.2007 14:28:15 Westeurop=E4ische Normalzeit schreibt= =20 jari.arkko@piuha.net: Finally, I hope that the research community (RRG, HIPRG, everyone else) will keep working on designs that go beyond what is presented above, including clean-slate identifier-locator split architectures, new routing paradigms such as compact routing, etc. Jari These lines remind me of heaving read "Toward Compact inter-domain routing"=20= =20 by Dmitri Krioukov and kc claffy a while ago, where it is explained (?)/ =20 asserted (?) "4 Why hierarchical routing will not work".=20 I hope this point of view (from August 2005) is not the latest. Stating=20 that hierarchical routing would stretch the routes needs to add some excu= se:=20 hierarchical routing as understood by the authors.=20 =20 Another word about IPv6: Isn't shim6 itself a best proof that the IPv6-header can't be the solution =20 for the future ?=20 =20 Heiner =20 =20 =20 -------------------------------1173970018 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 15.03.2007 14:28:15 Westeurop=E4ische Normalzeit sch= reibt=20 jari.arkko@piuha.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>Finally,=20 I hope that the research community (RRG, HIPRG,
everyone else) will kee= p=20 working on designs that go beyond
what is presented above, including=20 clean-slate identifier-locator
split architectures, new routing paradig= ms=20 such as compact
routing, etc.

Jari
 
These lines remind me of heaving read "Toward Compact inter-domain rout= ing"=20 by Dmitri Krioukov and kc claffy a while ago, where it is explained (?)/=20 asserted (?) "4 Why hierarchical routing will not work".
I hope this point of view (from  August 2005) is not the latest.&n= bsp;=20 Stating that  hierarchical routing  would stretch the routes needs= to=20 add some excuse: hierarchical routing as understood by the authors.
 
Another word about IPv6:
Isn't shim6 itself a best proof that the IPv6-header can't be the solut= ion=20 for the future ?
 
Heiner
 
 
-------------------------------1173970018-- --===============0070849037== 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 --===============0070849037==-- From ram-bounces@iab.org Thu Mar 15 11:44: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 1HRs43-0006tw-2C; Thu, 15 Mar 2007 11:40:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRs42-0006tq-5p for ram@iab.org; Thu, 15 Mar 2007 11:40:26 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRs3z-0002Om-P3 for ram@iab.org; Thu, 15 Mar 2007 11:40:26 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2FFde0h003300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Mar 2007 16:39:40 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <45F94921.7010707@piuha.net> References: <45F94921.7010707@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on Date: Thu, 15 Mar 2007 16:38:38 +0100 To: Jari Arkko X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.3 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: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 15-mrt-2007, at 14:24, Jari Arkko wrote: > My first suggestion is that it makes sense to divide and > conquer. I think we have some low-hanging fruit that > deserve to picked early, and we some architectural > work that will take time to develop and even more to > deploy. In addition, I think there is also some work that isn't exactly low hanging, but not architectural either. This is the fairly boring stuff that just needs to be done at some point so we can avoid future problems. What I'm thinking of here is increasing the average size of IP packets, because the bad stuff, such as the number of FIB lookups required, typically scales at O(#packets) while the good stuff typically scales at O(bandwidth). Currently, it's almost inconceivable that an IP packet crossing the commercial internet is larger than 1500 bytes. The reason is that ethernet rules the world these days, and although today's 1 and 10 Gbps ethernet has very little in common with the original 10 Mbps version, the faster versions did inherit the 1500 byte maximum packet size because there is no fragmentation at the ethernet layer so without a common maximum you can't interconnect the different speeds. So what we need to do is make it possible for IP systems with different maximum packet sizes to live on the same subnet and we probably have to do some work on PMTUD as well to increase its reliability. Boring, annoying and little short term gain. But if we can do this now, we'll be in a much better position to take advantage of advancements in transmission technology. On the low hanging fruit side: a new BGP metric that helps with traffic engineering could be very helpful in reducing the practice of announcing lots of small address blocks rather than a single large one. > For instance, looking at some data that Geoff showed > me a while ago, it seems that highest BGP update activity is > concentrated to a small set of players. Is there something > that we can do in BGP to recognize these cases and deal > with them in a more efficient manner. I think this is one > of the topics that RTGAREA will talk about on Thursday. Hm, didn't we have flap dampening for that? > There are probably more issues like that in the routing > space, low hanging fruit that improves the general > performance of the routing system. My big question that is still waiting for a good answer: do we really want to continue running some form of BGP4 for years to come? We can fix all the incidental problems but the architectural ones won't go away. (Meaning problems with the BGP architecture, not with the R/A architecture at large.) > Even if we can scale routers > to certain size of the Internet at a certain time, if we > had more architectural tools in our hands, perhaps we > could support a bigger Internet with them, or sooner. Or > with more multihoming, traffic engineering, or permanent > address space than otherwise possible. I can't get my personal > PI space, big companies can -- is that as it should be, or > something to be improved upon? It works the other way around: anyone who can satisfy the baroque RIR policy requirements can get address space and an AS number, and subsequently inject one or more prefixes into the global routing table and then we all have to buy bigger routers to accommodate the growth. Those RIR policies are basically the only barrier to entry, and they're not designed to function as such, so they're not doing a good job of it. Increasing router capacity won't provide any benefits to the community (as opposed to us who are having these discussions) because the community is already behaving as though router capacity is limitless. > But what would be the properties of the solution we are > looking for be? 0. It has to actually work 1. Cost and benefits are aligned 2. Deployable _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 15 12:35:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRssw-00023S-IH; Thu, 15 Mar 2007 12:33:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRssv-00023I-Tw for ram@iab.org; Thu, 15 Mar 2007 12:33:01 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRssu-0008Mg-K6 for ram@iab.org; Thu, 15 Mar 2007 12:33:01 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 15 Mar 2007 09:33:00 -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 l2FGWuVZ021352; Thu, 15 Mar 2007 09:32:56 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l2FGWdEs015767; Thu, 15 Mar 2007 16:32:49 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); Thu, 15 Mar 2007 09:32:29 -0700 Received: from [192.168.0.103] ([10.21.113.11]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 09:32:29 -0700 In-Reply-To: <45F94921.7010707@piuha.net> References: <45F94921.7010707@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B20951E-7BAE-455B-8D4B-FDFE52FF427A@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] what we should be working on Date: Thu, 15 Mar 2007 09:32:23 -0700 To: Jari Arkko X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Mar 2007 16:32:29.0288 (UTC) FILETIME=[85FBFE80:01C7671F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=851; t=1173976376; x=1174840376; 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]=20what=20we=20should=20be=20working=20on |Sender:=20; bh=n+ii94lf/KbFADOMyO/tjvVluhsQitIi1FjYuKxrt3U=; b=YxM3mAwQ4bLKXClHf3lzz667gIXqBZcdQ8wlZYqPVWWgph80TmhjOEHj8+RuxyxL644D+moq 6dvxEO9Ho9NnSDZQv6W59MnR6RsxdwI2ah7ha7w6ufABmq6DOY4pZ92tFgKUfROp+4VOcb6KZv mmEsAcUdVbbLuXj/gM9lO/SxI=; 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: 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 On Mar 15, 2007, at 6:24 AM, Jari Arkko wrote: > Another update related issue is that I'm the final IESG > blessing away from getting NEMO WG rechartered to > produce an efficient scheme for the airline industry's > mobility problem. I think this is doable without incurring > either a lengthy tunneling delay or a huge BGP impact. Why is this necessary? A solution seems straightforward: Establish a VPN that carries per-plane prefixes. Have the VPN touch the Internet at numerous large interconnects and advertise an aggregated prefix. Traffic to the plane now travels to the nearest interconnect and is then tunneled to the actual uplink. BGP is protected as only fixed aggregates are injected. Stretch is not bad, as packets would have most likely flowed to the major interconnect anyway. Regards, Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 15 13:05: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 1HRtL8-000494-RK; Thu, 15 Mar 2007 13:02:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRtL8-00048y-1P for ram@iab.org; Thu, 15 Mar 2007 13:02:10 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRtL6-0003ZE-PB for ram@iab.org; Thu, 15 Mar 2007 13:02:10 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8014F198720; Thu, 15 Mar 2007 19:01:46 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2B64419871E; Thu, 15 Mar 2007 19:01:46 +0200 (EET) Message-ID: <45F97BFC.4020707@piuha.net> Date: Thu, 15 Mar 2007 19:01:48 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Tony Li Subject: Moving networks (Was: Re: [RAM] what we should be working on) References: <45F94921.7010707@piuha.net> <8B20951E-7BAE-455B-8D4B-FDFE52FF427A@cisco.com> In-Reply-To: <8B20951E-7BAE-455B-8D4B-FDFE52FF427A@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: de4f315c9369b71d7dd5909b42224370 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, > A solution seems straightforward: > > Establish a VPN that carries per-plane prefixes. Have the VPN touch > the Internet at numerous large interconnects and advertise an > aggregated prefix. Traffic to the plane now travels to the nearest > interconnect and is then tunneled to the actual uplink. Right. I was thinking along these lines, actually. There are some details to think about of course, and maybe even some specification work. In any case, provide some guidance to the airline community on how they can deal with their problem. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 15 14:25: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 1HRuWI-0007Bk-79; Thu, 15 Mar 2007 14:17:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRuWH-00078E-2m for ram@iab.org; Thu, 15 Mar 2007 14:17:45 -0400 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRuQo-0000N9-SB for ram@iab.org; Thu, 15 Mar 2007 14:12:15 -0400 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 721F8C2A0 for ; Thu, 15 Mar 2007 14:12:03 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2FIBuVt029588; Thu, 15 Mar 2007 14:11:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2FIBpN9012759; Thu, 15 Mar 2007 14:11:51 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 6McsRivWPT9M; Thu, 15 Mar 2007 14:11:51 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id l2FIBn9N012745;Thu, 15 Mar 2007 14:11:49 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 11FD64FE4F; Thu, 15 Mar 2007 14:08:14 -0400 (EDT) Date: Thu, 15 Mar 2007 14:08:14 -0400 From: Wesley Eddy To: Tony Li Subject: Re: [RAM] what we should be working on Message-ID: <20070315180814.GC11002@grc.nasa.gov> References: <45F94921.7010707@piuha.net> <8B20951E-7BAE-455B-8D4B-FDFE52FF427A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8B20951E-7BAE-455B-8D4B-FDFE52FF427A@cisco.com> User-Agent: Mutt/1.5.5.1i X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:6 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) 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 Reply-To: weddy@grc.nasa.gov List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Thu, Mar 15, 2007 at 09:32:23AM -0700, Tony Li wrote: > > On Mar 15, 2007, at 6:24 AM, Jari Arkko wrote: > > >Another update related issue is that I'm the final IESG > >blessing away from getting NEMO WG rechartered to > >produce an efficient scheme for the airline industry's > >mobility problem. I think this is doable without incurring > >either a lengthy tunneling delay or a huge BGP impact. > > > Why is this necessary? A solution seems straightforward: > > Establish a VPN that carries per-plane prefixes. Have the VPN touch > the Internet at numerous large interconnects and advertise an > aggregated prefix. Traffic to the plane now travels to the nearest > interconnect and is then tunneled to the actual uplink. > > BGP is protected as only fixed aggregates are injected. Stretch is > not bad, as packets would have most likely flowed to the major > interconnect anyway. > This basic approach seems reasonable at first, and I believe that ICAO (the standards body for aeronautics) has considered it to some extent. One of the things to consider though is that VPN gateway redundancy mechanisms may be non-standard (at best) at the moment, and this is important to the stake-holders. For a few other reasons, those of us here who have been considering the problem think that NEMO offers the strongest solution. One point to clarify is that the "airline industry" (corporate) is really only one facet of aeronautical communications. Networking for air-traffic control (international governmental) is also important and coordinating a VPN for this purpose may be practically much more difficult than it is for an airline's needs. We've been working on a requirements draft for NEMO route optimization in aeronautics that explains some of this more, and can share in a couple weeks time. -- Wesley M. Eddy Verizon Federal Network Systems _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 15 14:25: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 1HRubS-00081F-AM; Thu, 15 Mar 2007 14:23:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRubQ-00081A-F2 for ram@iab.org; Thu, 15 Mar 2007 14:23:04 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRubP-0005C9-1N for ram@iab.org; Thu, 15 Mar 2007 14:23:04 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 15 Mar 2007 11:23:02 -0700 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 l2FIN2ia016391; Thu, 15 Mar 2007 11:23:02 -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 l2FIMiMJ013096; Thu, 15 Mar 2007 18:22:51 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); Thu, 15 Mar 2007 11:22:49 -0700 Received: from [192.168.0.103] ([10.21.144.219]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 11:22:48 -0700 In-Reply-To: <20070315180814.GC11002@grc.nasa.gov> References: <45F94921.7010707@piuha.net> <8B20951E-7BAE-455B-8D4B-FDFE52FF427A@cisco.com> <20070315180814.GC11002@grc.nasa.gov> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5318C32C-DD63-4692-9230-1A21E957FAF3@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] what we should be working on Date: Thu, 15 Mar 2007 11:22:42 -0700 To: weddy@grc.nasa.gov X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Mar 2007 18:22:48.0888 (UTC) FILETIME=[EF92CB80:01C7672E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=989; t=1173982982; x=1174846982; 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]=20what=20we=20should=20be=20working=20on |Sender:=20; bh=5gRWojXkBXzOVFzNojngfRzW9mb8sUCXuzaFStTZiSE=; b=GavlWsj/tiL7TOHAyhmL6obTdydITOl5kZoopeh9pTt6bx5jZpyCbQE//We1SciRn8EQM+Yd HszerlXKrbKmLiKyakyGIf95YITyTZgBYyXYA7x2ojwZL7jHSOGJVVYx; 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: 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 > We've been working on a requirements draft for NEMO route optimization > in aeronautics that explains some of this more, and can share in a > couple weeks time. Roger that, looking forward to it. > One of the things to consider though is that VPN gateway redundancy > mechanisms may be non-standard (at best) at the moment, and this is > important to the stake-holders. Please be sure that your draft expounds on this a bit more, as the normal business VPN requirements would seem to subsume this at first glance. > Networking for > air-traffic control (international governmental) is also important and > coordinating a VPN for this purpose may be practically much more > difficult than it is for an airline's needs. Interesting. What would ATC have to do with NEMO? Given the highly critical nature of ATC, I would hope that it would be strongly secured with respect to both passenger traffic and the rest of the Internet. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 15 19:25: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 1HRzIA-0001Ls-4J; Thu, 15 Mar 2007 19:23:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRzI9-0001Lk-1g for ram@iab.org; Thu, 15 Mar 2007 19:23:29 -0400 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRzI6-0007Pi-1g for ram@iab.org; Thu, 15 Mar 2007 19:23:29 -0400 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id MAA07053; Fri, 16 Mar 2007 12:23:16 +1300 In-Reply-To: <5318C32C-DD63-4692-9230-1A21E957FAF3@cisco.com> References: <45F94921.7010707@piuha.net> <8B20951E-7BAE-455B-8D4B-FDFE52FF427A@cisco.com> <20070315180814.GC11002@grc.nasa.gov> <5318C32C-DD63-4692-9230-1A21E957FAF3@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7322DC72-CAF3-4697-8DCF-B99C0A641A17@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [RAM] what we should be working on Date: Fri, 16 Mar 2007 12:23:39 +1300 To: Tony Li X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 16/03/2007, at 7:22 AM, Tony Li wrote: > >> Networking for >> air-traffic control (international governmental) is also important >> and >> coordinating a VPN for this purpose may be practically much more >> difficult than it is for an airline's needs. > > > Interesting. What would ATC have to do with NEMO? Given the > highly critical nature of ATC, I would hope that it would be > strongly secured with respect to both passenger traffic and the > rest of the Internet. > > Tony The interesting thing about ATC traffic is that during cruise the critical requirements are that the messages be authenticated and reasonably timely, but it isn't all that critical that they actually be delivered since the whole system is designed to safely deal with the occasional loss of communication (usually at the expense of a whole lot of fuel if the outage is prolonged). One of the issues that the airspace system is facing is congestion on voice frequencies, especially over the oceans because there are not that many frequencies to use, and I'm sure an IP based system using textual communication would greatly reduce that problem. You could do ATC over Jabber using certificates for message authentication, and that would certainly be an improvement over what is there now, provided you can get the IP connectivity. Andrew _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 16 10:52: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 1HSDkI-0007JV-VA; Fri, 16 Mar 2007 10:49:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSDkG-0007JB-CV for ram@iab.org; Fri, 16 Mar 2007 10:49:28 -0400 Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSDk6-0000W9-8g for ram@iab.org; Fri, 16 Mar 2007 10:49:28 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l2GEnFe1052640 for ; Fri, 16 Mar 2007 14:49:15 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l2GEnEiL1900704 for ; Fri, 16 Mar 2007 14:49:15 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l2GEnEGR022251 for ; Fri, 16 Mar 2007 14:49:14 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l2GEnE3G022247; Fri, 16 Mar 2007 14:49:14 GMT Received: from [9.4.211.10] ([9.4.211.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA347454; Fri, 16 Mar 2007 15:49:12 +0100 Message-ID: <45FAAE66.5050706@zurich.ibm.com> Date: Fri, 16 Mar 2007 15:49:10 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Geoff Huston Subject: Re: [RAM] PASH: Another SHIM6 proxying draft, in addition to pshim6 References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> <0B6CD3B7-0B90-4E9F-AEC0-55E417865F2E@nomadiclab.com> <45EC406E.1060901@zurich.ibm.com> <7.0.0.16.2.20070306091137.013b4648@apnic.net> In-Reply-To: <7.0.0.16.2.20070306091137.013b4648@apnic.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Pekka Nikander , 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-03-05 23:16, Geoff Huston wrote: > >> How will pash deal with TCP relays along the path (which >> recompute the TCP checksum)? This is an open issue for shim6 >> and pshim6. > > > At some point the extended legacy of a small number of demented pieces > of middleware simply has to stop. Any intermediary system performing TCP > and UDP checksums on packets on the fly is simply generating heat > rather then an enlightened state of blissful protection! Adjusting > generic end-to-end behaviours for such deranged middleware is, imho, a > collective waste of time. > > So, no I don't see this was an open issue for shim6. I'm actually quite happy with the middlebox text Marcelo has proposed in shim6. We can't pretend that silly middleboxes don't exist, but let's at least document what they need to do or not do. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 16 11:02: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 1HSDv8-0004iY-4t; Fri, 16 Mar 2007 11:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSDv7-0004iS-7s for ram@ietf.org; Fri, 16 Mar 2007 11:00:41 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSDv4-0002IT-Qg for ram@ietf.org; Fri, 16 Mar 2007 11:00:41 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id l2GF0b0O073206 for ; Fri, 16 Mar 2007 15:00:37 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l2GF0bmW2007262 for ; Fri, 16 Mar 2007 16:00:37 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l2GF0bk8002630 for ; Fri, 16 Mar 2007 16:00:37 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l2GF0apx002617; Fri, 16 Mar 2007 16:00:36 +0100 Received: from [9.4.211.10] ([9.4.211.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA325400; Fri, 16 Mar 2007 16:00:36 +0100 Message-ID: <45FAB112.6010000@zurich.ibm.com> Date: Fri, 16 Mar 2007 16:00:34 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] Pre-draft: mapper protocol References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ram@ietf.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 we should up-level and consider the generic options for distributing mapping information, that are hinted at in draft-wang-ietf-efit-00.txt. Actually I think there are more options than covered there, but that is the first discussion IMHO (since it seems obvious that mapping is needed in some shape or form). Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 17 12:06: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 1HSbMS-00012G-AS; Sat, 17 Mar 2007 12:02:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSbMQ-00011x-TY for ram@iab.org; Sat, 17 Mar 2007 12:02:26 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSbMN-0002EQ-Fd for ram@iab.org; Sat, 17 Mar 2007 12:02:24 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 37250198720; Sat, 17 Mar 2007 18:02:05 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B25CF1986E0; Sat, 17 Mar 2007 18:02:04 +0200 (EET) Message-ID: <45FC10FD.2060507@piuha.net> Date: Sat, 17 Mar 2007 18:02:05 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on References: <45F94921.7010707@piuha.net> In-Reply-To: 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 Iljitsch, > > In addition, I think there is also some work that isn't exactly low > hanging, but not architectural either. This is the fairly boring stuff > that just needs to be done at some point so we can avoid future problems. Yes. > > What I'm thinking of here is increasing the average size of IP > packets, because the bad stuff, such as the number of FIB lookups > required, typically scales at O(#packets) while the good stuff > typically scales at O(bandwidth). I am all for increasing the average size of packets. But I'll note that its probably not a panacea. Router cost, for instance, is a function of many factors, including FIB looks, filtering, fancy prioritizing schemes as well as line speed. And Path MTU increase is one of those nasty things where the weakest link counts, so getting that deployed requires updates in several places. But yes, I think it would still be useful. > On the low hanging fruit side: a new BGP metric that helps with > traffic engineering could be very helpful in reducing the practice of > announcing lots of small address blocks rather than a single large one. > Yes. >> For instance, looking at some data that Geoff showed >> me a while ago, it seems that highest BGP update activity is >> concentrated to a small set of players. Is there something >> that we can do in BGP to recognize these cases and deal >> with them in a more efficient manner. I think this is one >> of the topics that RTGAREA will talk about on Thursday. > > Hm, didn't we have flap dampening for that? We did -- what I have been told is that looking at the data, a large part of the update activity comes from a small number of sources that do this either intentionally or unintentionally. The question is, can we do something smarter about the high-activity sources than we currently do? I do not pretend to be an expert on what we could do, but I understood that there might be some ideas. Improve over the flap dampening design, perhaps, or make it more suitable for our current situation. Ross, John, Geoff should know more about this. >> There are probably more issues like that in the routing >> space, low hanging fruit that improves the general >> performance of the routing system. > > My big question that is still waiting for a good answer: do we really > want to continue running some form of BGP4 for years to come? We can > fix all the incidental problems but the architectural ones won't go > away. (Meaning problems with the BGP architecture, not with the R/A > architecture at large.) That is a good question, too. Not a low hanging fruit! Maybe another long-term architecture topic for the routing area to consider? Do other people feel that this work is something should be pursued? >> But what would be the properties of the solution we are >> looking for be? > > 0. It has to actually work > 1. Cost and benefits are aligned > 2. Deployable Nice summary. Those are the key issues. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 18 11:31: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 1HSxLH-0001SK-VK; Sun, 18 Mar 2007 11:30:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSxLG-0001SF-GO for ram@iab.org; Sun, 18 Mar 2007 11:30:42 -0400 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSxLF-0001eM-8m for ram@iab.org; Sun, 18 Mar 2007 11:30:42 -0400 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 342E053E0FC; Sun, 18 Mar 2007 10:30:30 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id nD7nORtRKd+6; Sun, 18 Mar 2007 10:30:24 -0500 (EST) Received: from [172.16.13.202] (dsl093-003-111.det1.dsl.speakeasy.net [66.93.3.111]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 95B9053E0EA; Sun, 18 Mar 2007 10:30:23 -0500 (EST) In-Reply-To: <45FC10FD.2060507@piuha.net> References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> 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: John G. Scudder Subject: Re: [RAM] what we should be working on Date: Sun, 18 Mar 2007 11:30:20 -0400 To: Jari Arkko , Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) 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 Mar 17, 2007, at 12:02 PM, Jari Arkko wrote: >> On the low hanging fruit side: a new BGP metric that helps with >> traffic engineering could be very helpful in reducing the practice of >> announcing lots of small address blocks rather than a single large >> one. > > Yes. The historical record indicates that this is easier said than done. The most recent attempt at "helping with traffic engineering" is draft-ietf-as-pathlimit. I wouldn't say it "reduces the practice of announcing lots of small address blocks rather than a single large one", though it does potentially restrict their scope. If you have something more powerful in mind, you should propose it, especially if it's straightforward enough to qualify as "low hanging fruit". --John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 18 11:53: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 1HSxgA-0002cg-RI; Sun, 18 Mar 2007 11:52:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSxg8-0002cE-Jv; Sun, 18 Mar 2007 11:52:16 -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 1HSxg7-00044x-EW; Sun, 18 Mar 2007 11:52:16 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l2IFq8K5004619; Sun, 18 Mar 2007 17:52:08 +0200 Date: Sun, 18 Mar 2007 17:52:08 +0200 (EET) From: Pekka Savola To: iab@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.90.1, clamav-milter version 0.90.1 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL, BAYES_40, NO_RELAYS 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: 67c1ea29f88502ef6a32ccec927970f0 Cc: ram@iab.org Subject: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt 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, 7 Mar 2007, Leslie Daigle wrote: > The IAB is ready to ask the RFC-Editor to publish > > Report from the IAB Workshop on Routing and Addressing > draft-iab-raws-report-01.txt ... > Please direct any comments to improve the clarity of > the report to the IAB (iab@iab.org) by April 4, 2007. Comments below. substantial ----------- Section 3.1.1 (Traffic Engineering) BGP and the common IGPs (OSPF, IS-IS) provide few tools for traffic engineering, so network operators usually achieve traffic engineering by "tweaking" the processing of routing protocols to achieve desired results. ... ==> This is not quite right as written. Both OSPF and IS-IS have TE extensions (OSPF even multiple ones AFAIR). It's not clear how TE extensions of IGPs help here so removing that part might clarify that part of this. It might also be arguable if BGP really provides only 'few tools for TE', given that people are using it in numerous ways today (e.g., AS-path prepending, de-aggregation, NOPEER and NOEXPORT communities, your upstreams' communities which control the route propagation properties and preferences). Maybe you were referring to (some vaguely defined) 'explicit' TE tools which would have been included in the protocol just for TE in mind? 3.2. IPv6 and its potential impact on routing table size Due to the increased IPv6 address size over IPv4, a full immediate transition to IPv6 is estimated to lead to the RIB and FIB sizes increasing by a factor of about four. he size of the routing table based on a more realistic assumption, that of parallel IPv4 and IPv6 routing for many years, is less clear. ==> I wouldn't go as far as to imply that the first sentence is clear, at the very least it requires a reference. Are you referring to the amount of memory required or the number of entries? Nonetheless I have trouble understanding this figure even if the current TE patterns persisted in the hypothetical full immediate transition to IPv6, given that ISPs and sites have a much smaller number of prefixes as with IPv4. 4.1.1. DRAM In routers, DRAM is used for storing the RIB and, in lower end routers, is also used for storing the FIB. ==> here and elsewhere in the draft the assumption seems to be that a high-end router cannot be built using DRAM. A recent presention by John Scudder in Apricot seems to indicate that this is possible though. While this may have been the conclusion in the workshop, a better wording might be more useful (e.g., examining whether the documents conclusions still hold even if DRAM was being used; toning down the language of off-chip SRAM necessity). 7.2.3 TE and IP overload On the surface, traffic engineering induced prefix de-aggregation seems orthogonal to the locator-identifier overloading problem. However this may not necessarily be true. Had all the IP prefixes been topologically aggregatable to start with, it would make re- aggregation possible or easier, when the finer granularity prefix announcements propagate further away from their origins. ==> I do not see how this conclusion is supported. If a customer uses PI, the advertisement _requires_ a DFZ slot. If a customer uses a subset of PA aggregate, a DFZ slot is not strictly required if the user doesn't wish to do TE. But if the customer wants to do TE, at least some TE slot is needed. So, given the assumption that we can't do away with TE, I don't see how topologically aggregatable would change the result. 7.3. Routing Convergence ==> Sections 7.1 and 7.2 were titled 'Problem [12]: ...', yet this one and the ones that follow aren't. Somewhat similar in 2.1-2.3. Were routing convergence (and the following sections) identified as problems or not? Some clarification to the titles and the text might be helpful. editorial --------- The document still has a number of '[Editor's note: ...]' paragraphs. Are these intended to be removed prior to publication or reworded somehow? 4.5. Summary Given the uncontrolled nature of it's growth rate, there is some ==> s/it's/its/ 7.2.1. Definition of Locator and Identifier Roughly speaking, the Internet comprises a transit backbone network and a large number of customer networks containing hosts that are attached to the backbone. Viewing the Internet as a graph, transit networks have branches and customer networks with hosts hang at the edges as leaves. ==> in the first sentence, 'a transit backbone network' might be misleading. A better way would be to say 'a large number of transit networks' or even 'thousands of transit networks' (applying Geoff's data and assuming transit network is one that provides transit to another AS number). From an ISP's viewpoint, identifiers identify customer networks and customer hosts. Note that the word identifier used here is definedEin the contextEof the Internet routing system; ==> something strange in the second sentence ('E' * 2) -- 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 Sun Mar 18 12:49:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSyVV-0002OC-EI; Sun, 18 Mar 2007 12:45:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSyVU-0002NZ-RJ for ram@iab.org; Sun, 18 Mar 2007 12:45:20 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSyVS-00032P-Eu for ram@iab.org; Sun, 18 Mar 2007 12:45:20 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Mar 2007 17:45:17 +0100 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 l2IGjHQo017579; Sun, 18 Mar 2007 17:45:17 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2IGjDlZ017485; Sun, 18 Mar 2007 16:45:13 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 17:45:13 +0100 Received: from [10.0.1.235] ([10.61.64.239]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Mar 2007 17:45:13 +0100 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: <8C689597-5505-4484-82B6-2441A378C5CC@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Sun, 18 Mar 2007 17:45:08 +0100 To: Pekka Savola X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 18 Mar 2007 16:45:13.0162 (UTC) FILETIME=[CC872AA0:01C7697C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3407; t=1174236317; x=1175100317; c=relaxed/simple; s=amsdkim2001; 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]=20Re=3A=20Impending=20publication=3A=20draft-ia b-raws-report-01.txt=20 |Sender:=20; bh=+MEK/JMp1B4hlFZrcVcWUBH/EIDSdTqk6pDujKcG/74=; b=qkd+0k6yN9WQ174IAWtdRhFDgpjfHXPUfsJaZAKKAKhjInSvcbrIlvBrAdfYrtffGzpnTCB4 SBrrxl1SJLI8mhPknqbMhAW1Tag+mkDxrQy+c/dbvKUDQRmWYi8tVI/y; Authentication-Results: ams-dkim-2; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: iab@ietf.org, 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 Pekka, > Section 3.1.1 (Traffic Engineering) > > BGP and the common IGPs (OSPF, IS-IS) provide few tools for traffic > engineering, so network operators usually achieve traffic > engineering > by "tweaking" the processing of routing protocols to achieve > desired > results. ... > > ==> This is not quite right as written. Both OSPF and IS-IS have TE > extensions (OSPF even multiple ones AFAIR). It's not clear how TE > extensions of IGPs help here so removing that part might clarify > that part of this. It might also be arguable if BGP really > provides only 'few tools for TE', given that people are using it in > numerous ways today (e.g., AS-path prepending, de-aggregation, > NOPEER and NOEXPORT communities, your upstreams' communities which > control the route propagation properties and preferences). Maybe > you were referring to (some vaguely defined) 'explicit' TE tools > which would have been included in the protocol just for TE in mind? Perhaps a fix would be to describe it as "few tools for inter-domain traffic engineering". > 3.2. IPv6 and its potential impact on routing table size > > Due to the increased IPv6 address size over IPv4, a full immediate > transition to IPv6 is estimated to lead to the RIB and FIB sizes > increasing by a factor of about four. he size of the routing table > based on a more realistic assumption, that of parallel IPv4 and > IPv6 > routing for many years, is less clear. > > ==> I wouldn't go as far as to imply that the first sentence is > clear, at > the very least it requires a reference. Are you referring to the > amount of > memory required or the number of entries? I believe it refers to the size of the entry. > Nonetheless I have trouble > understanding this figure even if the current TE patterns persisted > in the > hypothetical full immediate transition to IPv6, given that ISPs and > sites > have a much smaller number of prefixes as with IPv4 The comment stipulates a "full" transition to IPv6. While that might decrease the number of prefixes somewhat, one would still expect there to be an interestingly sized FIB and RIB. A lot of the really depends on address allocation policies and the actual address uptake. In a full transition where all sites get a PI prefix, I think that the number quoted above is extremely conservative, perhaps laughably so. > 4.1.1. DRAM > > In routers, DRAM is used for storing the RIB and, in lower end > routers, is also used for storing the FIB. > > ==> here and elsewhere in the draft the assumption seems to be that > a high-end > router cannot be built using DRAM. A recent presention by John > Scudder in > Apricot seems to indicate that this is possible though. It should be noted that John's presentation points to the use of RLDRAM. This is not your garden variety, consumer electronics store, stuff it in your PC yourself DRAM. > While this may have > been the conclusion in the workshop, a better wording might be more > useful > (e.g., examining whether the documents conclusions still hold even > if DRAM > was being used; toning down the language of off-chip SRAM necessity). A more specific phrasing, such as "commodity DRAM" would make the document more accurate. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 18 13:41: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 1HSzLj-00062D-NU; Sun, 18 Mar 2007 13:39:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSzLi-000621-51 for ram@iab.org; Sun, 18 Mar 2007 13:39:18 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSzLg-0000NU-VC for ram@iab.org; Sun, 18 Mar 2007 13:39:18 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7E05C872C9; Sun, 18 Mar 2007 13:39:16 -0400 (EDT) To: iab@ietf.org, ram@iab.org Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Message-Id: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> Date: Sun, 18 Mar 2007 13:39:16 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: jnc@mercury.lcs.mit.edu 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: Tony Li >> I have trouble understanding this figure even if the current TE >> patterns persisted in the hypothetical full immediate transition to >> IPv6 > The comment stipulates a "full" transition to IPv6. ... In a full > transition where all sites get a PI prefix, I think that the number > quoted above is extremely conservative, perhaps laughably so. The document probably ought to say roughly that (although I'd pick a different term, perhaps something like "extremely conservative, and perhaps a gross underestimate"); not sure if it already does. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 18 14:00: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 1HSzcS-0007xM-Bx; Sun, 18 Mar 2007 13:56:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSzcR-0007xE-VM for ram@iab.org; Sun, 18 Mar 2007 13:56:35 -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 1HSzcR-0003Wm-EU for ram@iab.org; Sun, 18 Mar 2007 13:56:35 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l2IHuYSN007570 for ; Sun, 18 Mar 2007 19:56:34 +0200 Date: Sun, 18 Mar 2007 19:56:34 +0200 (EET) From: Pekka Savola To: ram@iab.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.90.1, clamav-milter version 0.90.1 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=failed 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: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [RAM] network-based solutions: partial deployment, TE reqs 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, 28 Feb 2007, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Proxying Approach to SHIM6 and HIP (PASH) > Author(s) : P. Nikander, K. Slavov > Filename : draft-nikander-ram-pash-00.txt > Pages : 13 > Date : 2007-2-28 Just one comment and then some general observations of network-based solutions in general: Once the Internet core (all Tier 1 ISPs) have done the transition, deployment can gradually move towards the PASH 2 and/or 3 genres, where the identifiers are no longer routable through the core Internet. This will provide an incentive for sites to upgrade the ==> I'm not sure how well this works, given that most traffic on the internet does not go through tier 1 ISPs (but rather through peerings or upstreams at higher/lower tiers) ... Partial deployment (of network-based solutions) is more likely a more generic issue (also applying to LISP etc) though. It's not obvious to me why end-sites would want to bother with deploying anything if the alternative is "keep doing whatever you've been doing, no requirement to change anything". So, if we buy it that TE requirements currently in play will need to be satisfied, it means that a network-based solution would need to be deployed by those that feel the pain (end-sites necessarily don't), meaning tier1 and some tier2 networks. Further, it'd be unrealistic to assume that all of them would deploy the solution given that some are likely using routers capable of handling a higher number of prefixes yet (i.e., they don't feel the pain and/or don't see the impending pain in the near future). Frankly, to me it seems fulfilling all the TE requirements could likely mean that we'll end up duplicating current TE state from BGP (and it still stays in BGP due to backward compatibility) to the new protocol. So, if we're serious about allowing the TE usage that exists today, the protocol will need to be designed with TE support in mind from day one so that the requirements could be fulfilled in a more elegant way. (And I don't see any of the currently proposed solutions, including those at RRG, do that.) -- 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 Sun Mar 18 14:52: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 1HT0Sl-0005FL-2T; Sun, 18 Mar 2007 14:50:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT0Sk-0005F2-5o; Sun, 18 Mar 2007 14:50:38 -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 1HT0Si-0002sC-Lt; Sun, 18 Mar 2007 14:50:38 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l2IIoYEM008583; Sun, 18 Mar 2007 20:50:34 +0200 Date: Sun, 18 Mar 2007 20:50:34 +0200 (EET) From: Pekka Savola To: Noel Chiappa Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt In-Reply-To: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> Message-ID: References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.90.1, clamav-milter version 0.90.1 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS 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: 97adf591118a232206bdb5a27b217034 Cc: iab@ietf.org, 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 Sun, 18 Mar 2007, Noel Chiappa wrote: > >> I have trouble understanding this figure even if the current TE > >> patterns persisted in the hypothetical full immediate transition to > >> IPv6 > > > The comment stipulates a "full" transition to IPv6. ... In a full > > transition where all sites get a PI prefix, I think that the number > > quoted above is extremely conservative, perhaps laughably so. > > The document probably ought to say roughly that (although I'd pick a > different term, perhaps something like "extremely conservative, and perhaps > a gross underestimate"); not sure if it already does. First of all, what do you (and the draft) mean with 'full IPv6 transition'? The scenario where IPv4 has been shut off, or dual-stack everywhere? In any case this probably needs to be clarified. Especially if you mean 'everyone is using v6', I'm skeptical of these statements. Could someone give some ideas what exactly would contribute the IPv6 prefix count? I've trouble figuring how to get to even 100K prefixes (transforming the _current_ v4 routing table to v6; in 2050 the situation is likely different :-). The key point with IPv6 at the moment is that instead of an ISP having to have 100 identically-routed, non-contiguous prefixes, it could have just one or a couple of them. End-sites also often have non-contiguous prefixes which wouldn't (by routing policy) need to be deaggregated. -- 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 Sun Mar 18 15:21: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 1HT0tV-0004a1-OG; Sun, 18 Mar 2007 15:18:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT0tU-0004ZS-0y for ram@iab.org; Sun, 18 Mar 2007 15:18:16 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT0tR-0007bz-9k for ram@iab.org; Sun, 18 Mar 2007 15:18:16 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 06407872EE; Sun, 18 Mar 2007 15:18:12 -0400 (EDT) To: iab@ietf.org, ram@iab.org Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Message-Id: <20070318191812.06407872EE@mercury.lcs.mit.edu> Date: Sun, 18 Mar 2007 15:18:12 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: jnc@mercury.lcs.mit.edu 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: Pekka Savola >>> In a full transition where all sites get a PI prefix, I think that >>> the number quoted above is extremely conservative, perhaps >>> laughably so. >> The document probably ought to say roughly that Err, my comment was only about the "where all sites get a PI prefix" case, so I'm not how relevant your comments below are to the point I was commenting on. Anyway, moving on... > what do you (and the draft) mean with 'full IPv6 transition'? > ... In any case this probably needs to be clarified. I agree this could be better defined, since some potential meanings are almost meaningless - e.g. "every last IPv4-speaking host goes away" won't happen anytime in our lifetime, probably. So I'd say something like "very substantial IPv6 transition", and then define it as a percentage of the size of the IPv4 installed base - not sure what the appropriate %-age number is. > Could someone give some ideas what exactly would contribute the IPv6 > prefix count? I've trouble figuring how to get to even 100K prefixes Presumably many (but not all) of the same things that drive fragmentation in the IPv4 routing tables would drive it in the IPv6 tables too. There's likely to be less of some (e.g. going back for a second chunk of space because your initial allocation ran out - although we may still see some of that) and more of others (e.g. PI-space), and who knows how it will balance out. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 18 16:54:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT2L0-0006Y1-C7; Sun, 18 Mar 2007 16:50:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT2Kz-0006VD-26 for ram@iab.org; Sun, 18 Mar 2007 16:50:45 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT2Kv-0008CM-Jc for ram@iab.org; Sun, 18 Mar 2007 16:50:45 -0400 Received: from [192.168.1.182] (tulip-inn-terminus.fwa.tiscali.cz [195.146.103.206]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2IKmrkl078021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 18 Mar 2007 21:48:54 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B4329EF-2FCA-4176-AA7F-9E991A622224@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on Date: Sun, 18 Mar 2007 21:49:08 +0100 To: "John G. Scudder" X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=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: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 18-mrt-2007, at 16:30, John G. Scudder wrote: >>> On the low hanging fruit side: a new BGP metric that helps with >>> traffic engineering could be very helpful in reducing the >>> practice of >>> announcing lots of small address blocks rather than a single >>> large one. >> Yes. > The historical record indicates that this is easier said than > done. The most recent attempt at "helping with traffic > engineering" is draft-ietf-as-pathlimit. I wouldn't say it > "reduces the practice of announcing lots of small address blocks > rather than a single large one", though it does potentially > restrict their scope. > If you have something more powerful in mind, you should propose it, > especially if it's straightforward enough to qualify as "low > hanging fruit". Last year, I decided it would be fun to try and design a (somewhat) link state inter-domain routing protocol. It was indeed fun, so the time was well spent. (See http://www.muada.com/drafts/draft-van- beijnum-idle-00.txt for those who are curious.) One of the new aspects of that protocol was a real inter-AS metric. (Note that the BGP MED is sometimes called "inter-AS metric" but that's not what I'm talking about.) This metric would (in BGP) be a path attribute that holds an integer value that is increased at every hop. The length of the AS path, which is increased by one at each hop unless the operator takes measures to do something else, so in most cases, its value is one, two or three in the majority of cases. This is simply not granular enough. So the new inter-AS metric is increased by a value of at least 1 and maximum 127. The default would be 11. (The actual values depend on the choice for the number of bits in the iASm and the maximum number of hops that must be supported, we'll assume 15 and 256 for this example.) A -- B -- C / | \ me | observer \ | / D -- E -- F This means that after three intermediate hops, the AS path would hold four ASes at the observer. If the observer decides to send me traffic over C, B and A, and I don't like that, I can prepend the AS path over A but so for the observer, the path over C-B-A is now five hops and F-E-D four. But as a side effect, for B, the path over E and D has the same length as the prepended one over A, so I can very easily end up disrupting traffic flow severely. With the new iASm on the other hand, I can just send out a metric of 12 to A rather than the default 11. So for the observer, the metric of the path over C-B-A is 45 while D-E-F is 44. That's enough to make her send traffic over C-B-A if all else is equal. But for B, it's now 23 over A and 33 over E-D so nothing has changed. On the other hand, if I WANT to change the way B sends its traffic, I can increase my metric towards A to 22. So an inter-AS metric allows for more granular traffic engineering, which should make more specific announcements unnecessary in a certain fraction of all cases. Although this isn't entirely trivial and it will take some time to take effect, it doesn't disrupt current practice if implemented in BGP in a backward compatible way, so I think it's low hanging as IDR fruit goes. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 18 18:46: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 1HT44z-00079h-K9; Sun, 18 Mar 2007 18:42:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT44y-00079S-Vm; Sun, 18 Mar 2007 18:42:20 -0400 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT44x-0008OK-1W; Sun, 18 Mar 2007 18:42:20 -0400 Received: from [10.0.0.182] (dhcp-4009.ietf68.org [130.129.64.9]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id l2IMgEpF017428; Sun, 18 Mar 2007 15:42:14 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lixia Zhang Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Sun, 18 Mar 2007 15:42:12 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: iab@ietf.org, 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 Thanks for the comments, Pekka! (I was worried that none would come before the deadline:) On Mar 18, 2007, at 8:52 AM, Pekka Savola wrote: > ...... > Comments below. > > substantial > ----------- > > Section 3.1.1 (Traffic Engineering) > > BGP and the common IGPs (OSPF, IS-IS) provide few tools for traffic > engineering, so network operators usually achieve traffic > engineering > by "tweaking" the processing of routing protocols to achieve > desired > results. ... > > ==> This is not quite right as written. Both OSPF and IS-IS have TE > extensions (OSPF even multiple ones AFAIR). It's not clear how TE > extensions of IGPs help here so removing that part might clarify > that part of this. It might also be arguable if BGP really > provides only 'few tools for TE', given that people are using it in > numerous ways today (e.g., AS-path prepending, de-aggregation, > NOPEER and NOEXPORT communities, your upstreams' communities which > control the route propagation properties and preferences). Maybe > you were referring to (some vaguely defined) 'explicit' TE tools > which would have been included in the protocol just for TE in mind? Looks like we can just take Tony's suggested fix here. > 3.2. IPv6 and its potential impact on routing table size > > Due to the increased IPv6 address size over IPv4, a full immediate > transition to IPv6 is estimated to lead to the RIB and FIB sizes > increasing by a factor of about four. he size of the routing table > based on a more realistic assumption, that of parallel IPv4 and > IPv6 > routing for many years, is less clear. > > ==> I wouldn't go as far as to imply that the first sentence is > clear, at > the very least it requires a reference. Are you referring to the > amount of > memory required or the number of entries? Nonetheless I have trouble > understanding this figure even if the current TE patterns persisted > in the > hypothetical full immediate transition to IPv6, given that ISPs and > sites > have a much smaller number of prefixes as with IPv4. Read all the exchanges I saw so far. I agree that those "non- contiguous prefixes" from historical/legacy allocations are an issue today (e.g. UCLA has 5 or 6 prefixes) and a "clean slate allocation :)" of IPv6 addresses could help here. However, - our measurements have also shown that recently allocated IP blocks got fragmented as well (and the trend is increasing). - you surely know all these requests for PI prefixes... (I have not heard anyone who prefers PA to PI) > 4.1.1. DRAM > > In routers, DRAM is used for storing the RIB and, in lower end > routers, is also used for storing the FIB. > > ==> here and elsewhere in the draft the assumption seems to be that > a high-end > router cannot be built using DRAM. A recent presention by John > Scudder in > Apricot seems to indicate that this is possible though. While this > may have > been the conclusion in the workshop, a better wording might be more > useful > (e.g., examining whether the documents conclusions still hold even > if DRAM > was being used; toning down the language of off-chip SRAM necessity). again Tony's suggestion of "commodity DRAM" seems clarifying the concern here? > 7.2.3 TE and IP overload > > On the surface, traffic engineering induced prefix de-aggregation > seems orthogonal to the locator-identifier overloading problem. > However this may not necessarily be true. Had all the IP prefixes > been topologically aggregatable to start with, it would make re- > aggregation possible or easier, when the finer granularity prefix > announcements propagate further away from their origins. > > ==> I do not see how this conclusion is supported. If a customer > uses PI, > the advertisement _requires_ a DFZ slot. If a customer uses a > subset of PA > aggregate, a DFZ slot is not strictly required if the user doesn't > wish to > do TE. But if the customer wants to do TE, at least some TE slot > is needed. So, given the assumption that we can't do away with TE, > I don't see how > topologically aggregatable would change the result. do you see topologically aggregatable prefixes would have a better chance of re-aggregation? (I know there may be other subtle issues here but lets not go there) > 7.3. Routing Convergence > > ==> Sections 7.1 and 7.2 were titled 'Problem [12]: ...', yet this > one and > the ones that follow aren't. Somewhat similar in 2.1-2.3. Were > routing > convergence (and the following sections) identified as problems or > not? > Some clarification to the titles and the text might be helpful. To strive for a faithful report of the workshop outcome, Section 7.3 ends with the following paragraph: The workshop participants hold different views regarding (1) the severity of the routing convergence problem; and (2) whether it is an architectural problem, or an implementation issue. However, people generally agree that if we solve the routing scalability problem, that will certainly help reduce the convergence delay or make the problem a much easier one to handle because of the reduced number of routes to process. Isn't this clear enough to answer your question above? If not, any suggestions of how to revise it? > editorial > --------- We'll make sure to fix all the editorial issues you pointed. and Many thanks for this! Lixia _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 18 20:32:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5kN-0005pi-Ag; Sun, 18 Mar 2007 20:29:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5kL-0005om-FC for ram@iab.org; Sun, 18 Mar 2007 20:29:09 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT5kG-0005JS-4E for ram@iab.org; Sun, 18 Mar 2007 20:29:09 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Mar 2007 01:29:04 +0100 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 l2J0T3k3022781; Mon, 19 Mar 2007 01:29:03 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2J0T1lZ012798; Mon, 19 Mar 2007 00:29:03 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 01:29:01 +0100 Received: from [10.0.1.17] ([10.61.64.22]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 01:29:00 +0100 Message-ID: <45FDD946.4070005@cisco.com> Date: Mon, 19 Mar 2007 01:28:54 +0100 From: Mark Townsley User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt References: <8C689597-5505-4484-82B6-2441A378C5CC@cisco.com> In-Reply-To: <8C689597-5505-4484-82B6-2441A378C5CC@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2007 00:29:00.0774 (UTC) FILETIME=[9713C860:01C769BD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=905; t=1174264143; x=1175128143; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20Impending=20publication=3A=20draft-ia b-raws-report-01.txt |Sender:=20; bh=PYiYliECt+mZHOYmaojyHcAELFQW0sL0kYfmyghuN6g=; b=SEnheqfgiS0IwiZ8iyScDwOFdk0Pb0fh2tZwNeyp40EQJ0wUx56CeZIPoIayYKaSsOeICs6a e0JPYHF8HI8KY9LWsjYdHEmwzbOsXjnUVe+nBkI/KzTTMEJcrM33qTdv; Authentication-Results: ams-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: iab@ietf.org, 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 wrote: > > > It should be noted that John's presentation points to the use of > RLDRAM. This is not your garden variety, consumer electronics store, > stuff it in your PC yourself DRAM. Perhaps not stuffed in a PC for CPU memory, but stuffed in a video card doesn't seem far-fetched. Googling... http://www.ausmedia.com.au/HC3000%20_mitsubishi.html "Mitsubishi HC3000 Home Theatre Projector" (street price $1695) "High-Speed LVDS (low-voltage differential signals) Equipped with high-speed memory (RLDRAM) increases data transmission efficiency and high-speed LVDS drive to produce a high caliber gradation for a clean and clear image." In any case, I think we need to decide whether this document is about accurately recording what was said at the workshop, or trying to make all statements in the document accurate upon wider review. Which is it? - Mark _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 18 23:49:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT8mL-0006HU-Sq; Sun, 18 Mar 2007 23:43:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT8mK-0006HD-Tr for ram@iab.org; Sun, 18 Mar 2007 23:43:24 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HT8mG-0008L4-Hj for ram@iab.org; Sun, 18 Mar 2007 23:43:24 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 18 Mar 2007 20:43:16 -0700 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 l2J3hFkt019970; Sun, 18 Mar 2007 20:43:15 -0700 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2J3h7ZT011043; Mon, 19 Mar 2007 03:43:11 GMT Received: from vaf-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by vaf-lnx1.cisco.com (8.13.1/8.13.1) with ESMTP id l2J3h7CX021345; Sun, 18 Mar 2007 20:43:07 -0700 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.13.1/8.13.1/Submit) id l2J3h1wJ021344; Sun, 18 Mar 2007 20:43:01 -0700 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Sun, 18 Mar 2007 20:43:00 -0700 From: Vince Fuller To: Pekka Savola Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Message-ID: <20070319034300.GA21041@vaf-lnx1.cisco.com> References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3108; t=1174275795; x=1175139795; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20Impending=20publication=3A=20draft-ia b-raws-report-01.txt |Sender:=20; bh=MDGwQGEdOmxHc7KR3Y3OTDCcWQxiounP4mAokW+b9ug=; b=Jrc7LFmQKdOHVPqXZtAaIIlb2QOKjp39r3tMFFZan22qF8n048ftsetp352COuy70r+Xc0mz Xf3gEyYEWPd8qt2R4kWeF6jcKgfQqWT7VVkKy4gy+W+apNKTEdT8mr17; Authentication-Results: sj-dkim-3; header.From=vaf@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: iab@ietf.org, 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 > Especially if you mean 'everyone is using v6', I'm skeptical of these > statements. Could someone give some ideas what exactly would > contribute the IPv6 prefix count? I've trouble figuring how to get to > even 100K prefixes (transforming the _current_ v4 routing table to v6; > in 2050 the situation is likely different :-). > > The key point with IPv6 at the moment is that instead of an ISP having > to have 100 identically-routed, non-contiguous prefixes, it could have > just one or a couple of them. End-sites also often have > non-contiguous prefixes which wouldn't (by routing policy) need to be > deaggregated. It's very easy to see an ipv6 routing table exceeding 100K prefixes given the following set of assumptions and observations about how prefixes are routed and will be routed in the future: 1) Each site that has its own ASN for multi-homing requires a unique prefix. This gives 24K ipv6 prefixes if a wholescale replacement of IPv4 with ipv6 were to happen in a relatively short timeframe. This number has been growing linearly for some time. 2) The majority of more-specific prefixes in the global routing system are advertised intentionally for traffic engineering or other purposes. In other words, relatively few more-specifics are configuration errors that would go away if only network operators were better educated. One ipv6 prefix would be needed for each of the observed IPv4 more-specifics that are intentionally advertised today. This is 74K prefixes. 3) ipv6 is deployed in parallel to and with a degree of ubiquity that is similar to IPv4. 4) Multi-homing and traffic engineering will be done the same way with ipv6 as with IPv4, i.e. "PI for all" and advertisement of more-specifics for TE. All of the RIRs have modified their ipv6 assignment policies during the past year to enable/encourage such widescale "PI" use. 5) The trend will be toward at least as much multi-homing in the future as there is today. It's actually more likely that there will be *much more* multi-homing in the future as (and if) the Internet becomes a critical infrastructure requirement for business, as non-IP-based services are migrated to an IP-based substrate, and as it becomes ever less expensive to obtain multiple Internet connections (i.e. $19.99 for a DSL connection plus $19.99 for a cable connection isn't much of a barrier to entry, particularly if you have to buy those lines to get your IPTV-based TV and your VoIP-based phone service anyway) Using the first three assumptions, it is easy to see 100K ipv6 prefixes in the global routing system in a relatively short period of time. Applying the latter assumptions, adding the assumption that IPv4 continues in operational use indefinitely, and projecting recent growth patterns forward gives some interesting numbers. See: www.vaf.net/~vaf/rrg.pdf for more information (a presentation that I have given in various places, most recently at RRG on Saturday, over the past year). --Vince _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 01: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 1HTA2B-0006I3-Gi; Mon, 19 Mar 2007 01:03:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTA29-0006Hg-B4 for ram@iab.org; Mon, 19 Mar 2007 01:03:49 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTA28-0002s2-2z for ram@iab.org; Mon, 19 Mar 2007 01:03:49 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 18 Mar 2007 22:03:48 -0700 X-IronPort-AV: i="4.14,298,1170662400"; d="scan'208"; a="692471383:sNHT29549808" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l2J53YJ70779; Sun, 18 Mar 2007 22:03:34 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200703190503.l2J53YJ70779@merlot.juniper.net> To: Lixia Zhang Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt In-Reply-To: Your message of "Sun, 18 Mar 2007 15:42:12 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24163.1174280614.1@juniper.net> Date: Sun, 18 Mar 2007 22:03:34 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: iab@ietf.org, 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 Lixia, [clipped...] > > 4.1.1. DRAM > > > > In routers, DRAM is used for storing the RIB and, in lower end > > routers, is also used for storing the FIB. > > > > ==> here and elsewhere in the draft the assumption seems to be that > > a high-end > > router cannot be built using DRAM. A recent presention by John > > Scudder in > > Apricot seems to indicate that this is possible though. While this > > may have > > been the conclusion in the workshop, a better wording might be more > > useful > > (e.g., examining whether the documents conclusions still hold even > > if DRAM > > was being used; toning down the language of off-chip SRAM necessity). > > again Tony's suggestion of "commodity DRAM" seems clarifying the > concern here? I do not think Tony's suggestion is sufficient. The document needs to clearly spell out the implications of using RLDRAM instead of DRAM. Specifically, whether the document conclusions still hold even if one uses RLDRAM. Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 01:14: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 1HTAC4-0003K1-FN; Mon, 19 Mar 2007 01:14:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTAC2-0003Ic-P1; Mon, 19 Mar 2007 01:14:02 -0400 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTAC1-0003q0-35; Mon, 19 Mar 2007 01:14:02 -0400 Received: from vaioz1.apnic.net (dhcp13.potaroo.net [203.10.60.13]) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l2J5DoML047051; Mon, 19 Mar 2007 16:13:51 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070319161200.01398478@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 19 Mar 2007 16:14:45 +1100 To: Yakov Rekhter , Lixia Zhang From: Geoff Huston Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt In-Reply-To: <200703190503.l2J53YJ70779@merlot.juniper.net> References: <200703190503.l2J53YJ70779@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: iab@ietf.org, 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 04:03 PM 19/03/2007, Yakov Rekhter wrote: >Lixia, > >[clipped...] > > > > 4.1.1. DRAM > > > > > > In routers, DRAM is used for storing the RIB and, in lower end > > > routers, is also used for storing the FIB. > > > > > > ==> here and elsewhere in the draft the assumption seems to be that > > > a high-end > > > router cannot be built using DRAM. A recent presention by John > > > Scudder in > > > Apricot seems to indicate that this is possible though. While this > > > may have > > > been the conclusion in the workshop, a better wording might be more > > > useful > > > (e.g., examining whether the documents conclusions still hold even > > > if DRAM > > > was being used; toning down the language of off-chip SRAM necessity). > > > > again Tony's suggestion of "commodity DRAM" seems clarifying the > > concern here? > >I do not think Tony's suggestion is sufficient. The document >needs to clearly spell out the implications of using RLDRAM >instead of DRAM. Specifically, whether the document conclusions >still hold even if one uses RLDRAM. At some point this exercise ceases to be a report on the workshop and becomes something different. I don't recall any substantive discussion during the workshop on the implications of using RLDRAM in preference to DRAM. regards, Geoff _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 01:26: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 1HTANj-00013B-8t; Mon, 19 Mar 2007 01:26:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTANe-00011M-Pz for ram@iab.org; Mon, 19 Mar 2007 01:26:02 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTANd-00059q-Ec for ram@iab.org; Mon, 19 Mar 2007 01:26:02 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Mar 2007 06:26:01 +0100 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 l2J5Q0Hv024822; Mon, 19 Mar 2007 06:26:00 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2J5Q0lZ013843; Mon, 19 Mar 2007 05:26:00 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); Mon, 19 Mar 2007 06:26:00 +0100 Received: from [10.0.1.235] ([10.61.64.28]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 06:25:59 +0100 In-Reply-To: <200703190503.l2J53YJ70779@merlot.juniper.net> References: <200703190503.l2J53YJ70779@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: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Mon, 19 Mar 2007 06:25:56 +0100 To: Yakov Rekhter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Mar 2007 05:25:59.0575 (UTC) FILETIME=[13E90A70:01C769E7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=828; t=1174281960; x=1175145960; 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]=20Re=3A=20Impending=20publication=3A=20draft-ia b-raws-report-01.txt=20 |Sender:=20; bh=iKY7WxLyp+I439VEiyMntbucpWVkBSC1l4sq8iy49CY=; b=obGMNandJ6U4WGYGLQ3ZhIujkyW+JBzStInCa98LeBX5crj1HVRQHKHiFe2ORa8C2dmL7H+q EMoI1KbscSwaJ7TNl7ehx7+HyWpjMmT7FHMvAYfg+KD9Q08haRJ00a61; 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: ram@iab.org, iab@ietf.org, Lixia Zhang 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 Mar 19, 2007, at 6:03 AM, Yakov Rekhter wrote: > I do not think Tony's suggestion is sufficient. The document > needs to clearly spell out the implications of using RLDRAM > instead of DRAM. Specifically, whether the document conclusions > still hold even if one uses RLDRAM. Yakov, The implications of RLDRAM depend very much on the price history and long-term scalability of that particular technology in terms of latency and capacity. I'm very sorry, but I don't have such data currently. I hypothesize that the lower volumes of this specialized family of parts will take it off of the mass-market price curve and that Moore's law will not apply. Hard data here that would give us a read on the constant-cost growth of this technology would be very constructive. Regards, Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 02:12: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 1HTB1P-0005EQ-Fl; Mon, 19 Mar 2007 02:07:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTB1N-0005EC-Ga for ram@iab.org; Mon, 19 Mar 2007 02:07:05 -0400 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTB1J-0002FK-2i for ram@iab.org; Mon, 19 Mar 2007 02:07:05 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 8482C341B8; Mon, 19 Mar 2007 02:06:57 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 02:06:15 -0400 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] Architectural comments on draft-farinacci-lisp-00 Date: Mon, 19 Mar 2007 02:06:13 -0400 Message-ID: <816DD9299957E547B5D758D7F977D6DC019B2A6C@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Architectural comments on draft-farinacci-lisp-00 Thread-Index: AcdcpWasL6XHtCQoSlGOv2hU7TMcIgNRU/MQ References: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> <816DD9299957E547B5D758D7F977D6DC0179E968@tayexc14.americas.cpqcorp.net> From: "Bound, Jim" To: "Pekka Nikander" X-OriginalArrivalTime: 19 Mar 2007 06:06:15.0508 (UTC) FILETIME=[B3EB2940:01C769EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 Pekka N., I have read the below and updates to the respective drafts. I am still convinced we need to treat split loc/id as IRTF work and emerging technology. LISP is the direction we should follow to address RAWs problem space. In general across the IETF I support very limited and judicious use of middle boxes that are not router type nodes. =20 Note 1 - your solution at the edge will not work if two P2P clients on either end encrypt packet with IPsec only exposing the IP header (and with IPv6 some options). LISP will still work and one of my original questions to authors of LISP. LISP does not break E2E or transparency as the proxy approach will and a proxy for the RAWs solution causes additional network security problems as all proxies do today on the Internet. I do not consider LISP a proxy before others go there as a note too, but a routing function that is valid. Note 2 - the issues of attacks from RFC 4218 and the IP header are valid but the answer cannot be an IETF solution that unacceptable IPR claims from an Internet market business view for such a potential IETF spec solution that could exist on every node on the provincial Internet. Also I believe industry will address most of these out of IETF band solutions using IDS and IDP. Also LISP is transparent to the use of securing IP addresses and this is separate discussion. Note 3: I do believe your work on this is important research for the Internet community at large. Best, /jim > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Friday, March 02, 2007 3:33 AM > To: Bound, Jim > Cc: Thomas R Henderson; Dino Farinacci; ram@iab.org > Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 >=20 > Jim, >=20 > A few quick comments: >=20 > 1. Personally, I believe that we can do with SHIM6 (or HIP)=20 > what LISP aims to do either as easily, or at least almost as=20 > easily, as a fully developed version of LISP would do. We=20 > try to outline that in the PASH draft, >=20 > http://www.ietf.org/internet-drafts/draft-nikander-ram-pash-00.txt >=20 > 2. I started to analyse the design space related to id/loc split. =20 > However, given the time limits I didn't get that far, yet. =20 > The current version, mostly bare bones, is the ILSE draft: >=20 > http://www.ietf.org/internet-drafts/draft-nikander-ram-ilse-00.txt >=20 >=20 > Based on my/our argumentation therein, my tentative=20 > conclusions are the following: >=20 > We should go for a full-blown but simplified id/loc split,=20 > probably based on SHIM6. We could start by simplifying SHIM6=20 > quite a lot, e.g. by forgetting e.g. even SHIM6 multi-homing=20 > features, but still use the protocol and security framework,=20 > for *forward* compatibility. As far as I can see, running=20 > over IPv4 should not be a problem here; using=20 > IPv4-address-like identifiers may be a real challenge, but=20 > might be solvable for very early deployment, depending on=20 > your trust model. >=20 > Starting from LISP, you could get there by a) using the SHIM6=20 > protocol instead of ICMP, b) using SHIM6 tags instead of=20 > tunnelling (but this is not important), c) using CGAS as=20 > identifiers, and d) adopting the LISP 1.5 deployment=20 > approach, basically meaning separate =20 > routing infrastructures for IPv4 (locators) and IPv6 (identifiers). =20 > But I don't know if that was the best way, or even a good one. >=20 > Alternatively, you could start from PASH or PSHIM6, and end=20 > up at pretty much the same target. >=20 > Replacing the IPv6 routing infra with a DHT or similar would=20 > allow you to use ORCHIDs too, enabling HIP as a (forward=20 > compatible) option. >=20 >=20 > Trying to crystallise my standing: Removing the need for=20 > id/loc split for now would be a BAD thing for the Internet. =20 > Read Mark Handley's "Why the Internet just works." If we=20 > remove the energy that the community now has through yet=20 > another ugly pat^H^H^H^H^H point solution, I doubt we will=20 > ever get another chance to implement the id/loc split. >=20 > But then, losing the current opportunity might be a good=20 > thing for the clean slate approaches. :-) >=20 > --Pekka Nikander >=20 > On 2 Mar 2007, at 07:08, Bound, Jim wrote: >=20 > > LISP solution if accepted removes the need to do split=20 > ID/LOC for now. > > Also in my view watching this mail none have answered Brian=20 > Carpenters=20 > > mail on the issues of LOC/ID split and the trade-offs from=20 > some time=20 > > ago. That reinforces for me true split of LOC/ID is really an IRTF=20 > > effort not an IETF effort and will take a minimum of 5 years. What=20 > > LISP does is provides an opportunity to view a short term=20 > solution to=20 > > the RAM issues identified within LISP. I for one am not=20 > worried about=20 > > the encapsulation at ITR to ETR and decap at ETR. =20 > Additional security=20 > > can be specified and defense in depth with IPsec VPNs is achievable=20 > > over a routed network path. Also as LISP states this does not=20 > > preclude continued work on SHIM6, which I still think is=20 > important to=20 > > move forward. >=20 >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 03:20: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 1HTC6C-000314-9u; Mon, 19 Mar 2007 03:16:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTC6B-00030u-1V for ram@iab.org; Mon, 19 Mar 2007 03:16:07 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTC69-0006xp-K9 for ram@iab.org; Mon, 19 Mar 2007 03:16:07 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1EA41212F44; Mon, 19 Mar 2007 09:15:41 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 83F22212E2A; Mon, 19 Mar 2007 09:15:40 +0200 (EET) In-Reply-To: <816DD9299957E547B5D758D7F977D6DC019B2A6C@tayexc14.americas.cpqcorp.net> References: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> <816DD9299957E547B5D758D7F977D6DC0179E968@tayexc14.americas.cpqcorp.net> <816DD9299957E547B5D758D7F977D6DC019B2A6C@tayexc14.americas.cpqcorp.net> 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: Pekka Nikander Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Mon, 19 Mar 2007 09:15:39 +0200 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Jim, Thanks for reading the drafts and thinking about the situation. A few quick comments: > I have read the below and updates to the respective drafts. I am > still convinced we need to treat split loc/id as IRTF work and > emerging technology. LISP is the direction we should follow to > address RAWs problem space. You may well be right that not going for id/loc split but doing something like LISP (or rather eFIT, draft-wang-ietf-efit-00.txt) may be a better way to address the immediate RAWs problem space. OTOH, I think some rudimentary sort of id/loc split would be soon ready for wide deployment, if people decide to take the effort. That is, we are not quite there yet, but not that far either, IMHO. A large open question, IMHO, is whether we should aim for BOTH separating core routing from the edge addresses (a la eFit) AND the edge addresses from host identifiers, or aim for a combined approach. That'll be main my point on my very brief INT area presentation on Thursday. From an architectural point of view, I imagine a pattern emerging here: more layers. Perhaps something along the lines Joe Touch et al propose in their RNA (Recursive Network Architecture). > In general across the IETF I support very limited and judicious use > of middle boxes that are not router type nodes. I do not understand that comment of yours. I don't see any way to effectively fight DDoS (within the bounds of the current architecture) but add more intelligent middle boxes. If you still want to call them routers is just a matter of terminology. > Note 1 - your solution at the edge will not work if two P2P clients on > either end encrypt packet with IPsec only exposing the IP header (and > with IPv6 some options). I don't think so. IIRC, SHIM6 works below IPsec. Hence, it does not make any difference if the address rewriting is done at the host or a proxy. Besides, the tag extension header is not an important detail of SHIM6, IMHO. It could be replaced with tunnelling, at the expense of some header growth. > LISP does not break E2E or transparency as the proxy approach will > and a proxy for the RAWs solution causes additional network > security problems as all proxies do today on the Internet. I think you have gotten the issue wrong here, especially what comes to security. Security here does not depend so much whether you call the tunnelling/rewriting boxes as proxies or tunnel routers. It depends on your trust assumptions, identifier design, support infrastructure, and placement of the boxies. Writing my view of this to the ILSE draft is on my todo list, but unfortunately I'm far from it at this point of time. --Pekka _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 04:07: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 1HTCrR-0007JO-Eh; Mon, 19 Mar 2007 04:04:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTCrO-0007Hy-8z for ram@iab.org; Mon, 19 Mar 2007 04:04:55 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTCrN-0005q3-QH for ram@iab.org; Mon, 19 Mar 2007 04:04:54 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 23ECD198690; Mon, 19 Mar 2007 10:04:53 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B48E719867C; Mon, 19 Mar 2007 10:04:52 +0200 (EET) Message-ID: <45FE4424.2040403@piuha.net> Date: Mon, 19 Mar 2007 09:04:52 +0100 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt References: In-Reply-To: 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: iab@ietf.org, 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 Pekka, > 3.2. IPv6 and its potential impact on routing table size > > Due to the increased IPv6 address size over IPv4, a full immediate > transition to IPv6 is estimated to lead to the RIB and FIB sizes > increasing by a factor of about four. he size of the routing table > based on a more realistic assumption, that of parallel IPv4 and IPv6 > routing for many years, is less clear. > > ==> I wouldn't go as far as to imply that the first sentence is clear, at > the very least it requires a reference. Are you referring to the > amount of > memory required or the number of entries? Nonetheless I have trouble > understanding this figure even if the current TE patterns persisted in > the > hypothetical full immediate transition to IPv6, given that ISPs and sites > have a much smaller number of prefixes as with IPv4. As Vince noted, there's a lot of detail behind this point that we could get into. For parallel deployment, the report only says that the situation is unclear. Vince's mail seemed to indicate that the hypothetical switch-to-ipv6-only situation would result in 100K prefixes. This seems to double the table size (200K*4 vs. 100K*16). Is that a change that we should make, or are there other factors that should be counted in? Note that the parallel deployment, which Vince's and Jason's analysis looks at is a different case. > > 4.1.1. DRAM > > In routers, DRAM is used for storing the RIB and, in lower end > routers, is also used for storing the FIB. > > ==> here and elsewhere in the draft the assumption seems to be that a > high-end > router cannot be built using DRAM. A recent presention by John > Scudder in > Apricot seems to indicate that this is possible though. While this > may have > been the conclusion in the workshop, a better wording might be more > useful > (e.g., examining whether the documents conclusions still hold even if > DRAM > was being used; toning down the language of off-chip SRAM necessity). FWIW, I got a very different picture about the router design alternatives in Amsterdam than I have gotten since, listening to presentations like John's or talking directly or indirectly to various hardware engineers. I think it is important to know that there are different approaches to building routers, and that some approaches are nearer commodity hardware curves than others. I could take a look at the text and suggest some changes (without changing the journalistic nature of this report, of course). Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 04:22:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTD4p-0005qY-8s; Mon, 19 Mar 2007 04:18:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTD4o-0005qT-Sm for ram@iab.org; Mon, 19 Mar 2007 04:18:46 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTD4n-0007Ex-Ji for ram@iab.org; Mon, 19 Mar 2007 04:18:46 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Mar 2007 01:18:45 -0700 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 l2J8IjJj029895; Mon, 19 Mar 2007 01:18:45 -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 l2J8IiMF027683; Mon, 19 Mar 2007 08:18:44 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); Mon, 19 Mar 2007 01:18:44 -0700 Received: from [130.129.17.126] ([10.21.115.180]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 01:18:43 -0700 In-Reply-To: <816DD9299957E547B5D758D7F977D6DC019B2A6C@tayexc14.americas.cpqcorp.net> References: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> <816DD9299957E547B5D758D7F977D6DC0179E968@tayexc14.americas.cpqcorp.net> <816DD9299957E547B5D758D7F977D6DC019B2A6C@tayexc14.americas.cpqcorp.net> 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] Architectural comments on draft-farinacci-lisp-00 Date: Mon, 19 Mar 2007 01:18:42 -0700 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Mar 2007 08:18:44.0150 (UTC) FILETIME=[35ADAD60:01C769FF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=628; t=1174292325; x=1175156325; 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]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=GJLKMcnlJhv7sYlSCwjo3UQg7haCz1MU62DTYeqhPYw=; b=IBSQe8o25LkAukBwzDml2X3DGDHZIaqZiSf4J76DnolzveBk+X8//p18dAji2W1ysYrY1u+1 Z/8HoVMEAETF+0hN24rbz3nbz6Iey8zJTWmeIObAZE21CtwtkEZt0zKn; 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Pekka Nikander , 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 > Note 1 - your solution at the edge will not work if two P2P clients on > either end encrypt packet with IPsec only exposing the IP header (and > with IPv6 some options). LISP will still work and one of my original > questions to authors of LISP. LISP does not break E2E or transparency Agree, and as Noel has mentioned, LISP is a "jack-up" scheme meaning everything that runs "on top of the jack" doesn't know they are jacked-up. So you can jack-up with a short-term solution and either "jack-up again" with a possible long-term solution or replace the short-term with long-term with one jack. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 05:41:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTEJy-0005NJ-1o; Mon, 19 Mar 2007 05:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTEJx-0005NE-Fk for ram@iab.org; Mon, 19 Mar 2007 05:38:29 -0400 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTEJs-0000wA-F7 for ram@iab.org; Mon, 19 Mar 2007 05:38:28 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id A24B1340A3; Mon, 19 Mar 2007 05:38:21 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 05:38:21 -0400 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] Architectural comments on draft-farinacci-lisp-00 Date: Mon, 19 Mar 2007 05:38:19 -0400 Message-ID: <816DD9299957E547B5D758D7F977D6DC019B2A75@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Architectural comments on draft-farinacci-lisp-00 Thread-Index: Acdp9mrshgd+paY9RvemA9a23C//PgAEhgFg References: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> <816DD9299957E547B5D758D7F977D6DC0179E968@tayexc14.americas.cpqcorp.net> <816DD9299957E547B5D758D7F977D6DC019B2A6C@tayexc14.americas.cpqcorp.net> From: "Bound, Jim" To: "Pekka Nikander" X-OriginalArrivalTime: 19 Mar 2007 09:38:21.0466 (UTC) FILETIME=[552E3FA0:01C76A0A] 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 Hello Pekka N., Responses where I clarify further below.=20 > > I have read the below and updates to the respective drafts. I am=20 > > still convinced we need to treat split loc/id as IRTF work and=20 > > emerging technology. LISP is the direction we should follow=20 > to address=20 > > RAWs problem space. >=20 > You may well be right that not going for id/loc split but=20 > doing something like LISP (or rather eFIT,=20 > draft-wang-ietf-efit-00.txt) may be a better way to address=20 > the immediate RAWs problem space. I believe eFIT has synergy with LISP and the idea of DHTs is something that LISP 3 stated as possible goal, and I believe is better approach than DNS. Again I am supporting addressing the immediate need with model that will permit transition to new models which include evolution to loc/id split if the industry will move in that direction. > > In general across the IETF I support very limited and=20 > judicious use of=20 > > middle boxes that are not router type nodes. >=20 > I do not understand that comment of yours. I don't see any=20 > way to effectively fight DDoS (within the bounds of the current > architecture) but add more intelligent middle boxes. If you=20 > still want to call them routers is just a matter of terminology. Note I was careful above I said "judicious" use of them not to never use them. >=20 > > Note 1 - your solution at the edge will not work if two P2P=20 > clients on=20 > > either end encrypt packet with IPsec only exposing the IP=20 > header (and=20 > > with IPv6 some options). >=20 > I don't think so. IIRC, SHIM6 works below IPsec. Hence, it=20 > does not make any difference if the address rewriting is done=20 > at the host or a proxy. Besides, the tag extension header is=20 > not an important detail of SHIM6, IMHO. It could be replaced=20 > with tunnelling, at the expense of some header growth. The use of tag as tunnel would work I think need to think about that one. As I read your proxy I gleaned you had to look at TCP, I will recheck that read on my part. My point is any solution can only assume the IP header and with IPv6 options in front of the IPsec payload. >=20 > > LISP does not break E2E or transparency as the proxy=20 > approach will and=20 > > a proxy for the RAWs solution causes additional network security=20 > > problems as all proxies do today on the Internet. >=20 > I think you have gotten the issue wrong here, especially what=20 > comes to security. Security here does not depend so much=20 > whether you call the tunnelling/rewriting boxes as proxies or=20 > tunnel routers. It depends on your trust assumptions,=20 > identifier design, support infrastructure, and placement of=20 > the boxies. Writing my view of this to the ILSE draft is on=20 > my todo list, but unfortunately I'm far from it at this point of time. I don't think my view is wrong but my view of work to do first may be different than yours. I believe if we can reduce the pain in DFZ and for multihoming with initial edge solution much of RAWs problem space can be addressed at least initially. I think we need to view the network security problems (data in motion) to find multiple potential answers. Thanks for your hard work on all those specs it is a lot of work and appreciated by me in the IETF. /jim _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 07:07: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 1HTFeK-0005WZ-RJ; Mon, 19 Mar 2007 07:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTFeJ-0005WS-4Q for ram@iab.org; Mon, 19 Mar 2007 07:03:35 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTFeF-0004Yl-LT for ram@iab.org; Mon, 19 Mar 2007 07:03:35 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C2A4E198683; Mon, 19 Mar 2007 13:03:18 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2827519867C; Mon, 19 Mar 2007 13:03:18 +0200 (EET) Message-ID: <45FE6DF4.20303@piuha.net> Date: Mon, 19 Mar 2007 12:03:16 +0100 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 References: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> <816DD9299957E547B5D758D7F977D6DC0179E968@tayexc14.americas.cpqcorp.net> <816DD9299957E547B5D758D7F977D6DC019B2A6C@tayexc14.americas.cpqcorp.net> In-Reply-To: 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: ram@iab.org, "Bound, Jim" 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 Pekka, Jim, > You may well be right that not going for id/loc split but doing > something like LISP (or rather eFIT, draft-wang-ietf-efit-00.txt) may > be a better way to address the immediate RAWs problem space. > > OTOH, I think some rudimentary sort of id/loc split would be soon > ready for wide deployment, if people decide to take the effort. That > is, we are not quite there yet, but not that far either, IMHO. > > A large open question, IMHO, is whether we should aim for BOTH > separating core routing from the edge addresses (a la eFit) AND the > edge addresses from host identifiers, or aim for a combined approach. > That'll be main my point on my very brief INT area presentation on > Thursday. Yes, this is one of the big questions I would like to get an answer to. FWIW, I think there's something to be said for a modularization and making focused solutions to specific problems. But if we do that then we need to be very clear that it is indeed a solution for a very specific problem, not the grand tool to get rid of all the pain caused by the dual role of addresses. OTOH, some of the drafts seem to say that a more complete solution would also be possible. If that can be done without unreasonable difficulties, it should of course be preferred. I don't have a good sense yet on how easy or hard that would be. I'm hoping Pekka's presentation on Thursday will provide some light on that. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 08:43: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 1HTHA5-0007f6-CI; Mon, 19 Mar 2007 08:40:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTHA4-0007YN-7G for ram@iab.org; Mon, 19 Mar 2007 08:40:28 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTH9v-0004pJ-W2 for ram@iab.org; Mon, 19 Mar 2007 08:40:28 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by kremlin.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 19 Mar 2007 05:40:20 -0700 X-IronPort-AV: i="4.14,300,1170662400"; d="scan'208"; a="672433095:sNHT33422880" Received: from rcallon-lt1.juniper.net ([172.23.1.96]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l2JCe3J41945; Mon, 19 Mar 2007 05:40:04 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 19 Mar 2007 08:39:59 -0400 To: Yakov Rekhter , Lixia Zhang From: Ross Callon Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt In-Reply-To: <200703190503.l2J53YJ70779@merlot.juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: iab@ietf.org, 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 10:03 PM 3/18/2007 -0700, Yakov Rekhter wrote: >... >I do not think Tony's suggestion is sufficient. The document >needs to clearly spell out the implications of using RLDRAM >instead of DRAM. Specifically, whether the document conclusions >still hold even if one uses RLDRAM. > >Yakov. To me it seems like our understanding of the problem, and of potential solutions, continues to evolve over time (particularly as we look into the details more closely). As one example, I personally was not aware of the distinction between RLDRAM and regular DRAM when in Amsterdam, nor was this difference discussed in Amsterdam, but I have learned about this since returning from the workshop. This leads to a question: To what extent is the workshop report supposed to be an accurate description of what went on at the workshop, and to what extent is it supposed to be an accurate description of what we *now* feel is the problem and range of possible solutions? I haven't sent in detailed comment on the report because I think that it is an accurate description of what was discussed at the time in Amsterdam, and also because I don't think that our understanding of the problem will become static for quite a while (so if the document needs to reflect current improved understanding, it won't be fully stable for quite a while). The document's abstract states: This document reports the outcome of the Routing and Addressing Workshop which the Internet Architecture Board (IAB) held on October 18-19, 2006 in Amsterdam, Netherlands. ... Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not the IAB. According to the first sentence of the abstract I would not expect the document to be an accurate description of the more detailed or more precise work that has gone on since the workshop, nor an accurate reflection of the greater level of understanding that has occurred since (which to me appears to still have a long way to go). In fact, the last sentence is not quite right, since the views and positions documented in the report are those that were stated by workshop participants at the time, and do not necessarily reflect the *current* views of at least some of the workshop participants. Perhaps we should add an additional sentence to either the abstract or to the last paragraph of section 1 that says: Work on issues related to this workshop report is continuing, and this document does not intend to accurately reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. Ross _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 09:04:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTHW1-0002PT-7V; Mon, 19 Mar 2007 09:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTHVz-0002Ns-6i for ram@iab.org; Mon, 19 Mar 2007 09:03:07 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTHVw-0001GW-Vo for ram@iab.org; Mon, 19 Mar 2007 09:03:07 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6EF14872F9; Mon, 19 Mar 2007 09:03:04 -0400 (EDT) To: iab@ietf.org, ram@iab.org Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Message-Id: <20070319130304.6EF14872F9@mercury.lcs.mit.edu> Date: Mon, 19 Mar 2007 09:03:04 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: jnc@mercury.lcs.mit.edu 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: Ross Callon > ... our understanding of the problem, and of potential solutions, > continues to evolve over time ... > To what extent is the workshop report supposed to be an accurate > description of what went on at the workshop, and to what extent is it > supposed to be an accurate description of what we *now* feel is the > problem and range of possible solutions? Good point. I would say it should be both. IMO it would be misleading to the general public to publish a document saying "X is possible" when we now know that X is not possible. Rather, I think we should both document the meeting, as well as explicitly point out advances in understanding since then (as much as we know at the time of publication). To do that, invent some special syntax for labelling such post-meeting knowledge (and well note it at the start of the document), and the write things like "The meeting concluded that X is possible. {Note: Since the meeting, it has been discovered that X is not after all possible, because of Y.}" > I don't think that our understanding of the problem will become > static for quite a while ... Another good point; the document should say this explicitly, again, to warn people. (There's no point holding the document waiting for out understanding to stabilize; that's a moving target for a long time to come, is my guess.) Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 09:25: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 1HTHq9-0000GK-1U; Mon, 19 Mar 2007 09:23:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTHq7-0000Fo-Gd for ram@iab.org; Mon, 19 Mar 2007 09:23:55 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTHq1-0005vJ-EU for ram@iab.org; Mon, 19 Mar 2007 09:23:55 -0400 Received: from [130.129.22.254] ([::ffff:64.103.37.2]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 19 Mar 2007 09:19:37 -0400 id 015880EB.45FE8DE9.00000AEF Message-ID: <45FE8ED1.40900@thinkingcat.com> Date: Mon, 19 Mar 2007 09:23:29 -0400 From: Leslie Daigle User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Ross Callon Subject: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt References: <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> In-Reply-To: <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ram@iab.org, iab@ietf.org, Lixia Zhang 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 Ross, everyone, As has been noted by a few folks already, the purpose of this document is strictly and uniquely to document the discussion that occurred at the workshop. Lixia has already provided pointers to some of the disclaimer text in the document. The IAB is eager to publish the workshop report for the very reason that discussion and thinking have clearly moved on in the intervening months. It is time to close the workshop chapter and focus on the subsequent ones. Comments that help clarify the text as a representation of what was discussed at the event will be gratefully accepted for the document. Everything else -- is input to the current discussions (on RAM, RRG, ROAP, etc). Thanks, Leslie. Ross Callon wrote: > At 10:03 PM 3/18/2007 -0700, Yakov Rekhter wrote: >> ... >> I do not think Tony's suggestion is sufficient. The document >> needs to clearly spell out the implications of using RLDRAM >> instead of DRAM. Specifically, whether the document conclusions >> still hold even if one uses RLDRAM. >> >> Yakov. > > To me it seems like our understanding of the problem, and of > potential solutions, continues to evolve over time (particularly > as we look into the details more closely). As one example, I > personally was not aware of the distinction between RLDRAM > and regular DRAM when in Amsterdam, nor was this difference > discussed in Amsterdam, but I have learned about this since > returning from the workshop. > > This leads to a question: To what extent is the workshop report > supposed to be an accurate description of what went on at the > workshop, and to what extent is it supposed to be an accurate > description of what we *now* feel is the problem and range of > possible solutions? I haven't sent in detailed comment on the > report because I think that it is an accurate description of what > was discussed at the time in Amsterdam, and also because I > don't think that our understanding of the problem will become > static for quite a while (so if the document needs to reflect > current improved understanding, it won't be fully stable for quite > a while). > > The document's abstract states: > > This document reports the outcome of the Routing and Addressing > Workshop which the Internet Architecture Board (IAB) held on > October 18-19, 2006 in Amsterdam, Netherlands. > ... > Note that this document is a report on the proceedings of the > workshop. The views and positions documented in this report are > those of the workshop participants and not the IAB. > > According to the first sentence of the abstract I would not expect > the document to be an accurate description of the more detailed > or more precise work that has gone on since the workshop, nor > an accurate reflection of the greater level of understanding that has > occurred since (which to me appears to still have a long way to go). > In fact, the last sentence is not quite right, since the views and > positions documented in the report are those that were stated by > workshop participants at the time, and do not necessarily reflect > the *current* views of at least some of the workshop participants. > > Perhaps we should add an additional sentence to either the > abstract or to the last paragraph of section 1 that says: > > Work on issues related to this workshop report is continuing, > and this document does not intend to accurately reflect the > increased understanding of issues nor to discuss the range of > potential solutions that may be the outcome of this ongoing work. > > Ross > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 10:03: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 1HTIST-0004ih-Ll; Mon, 19 Mar 2007 10:03:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTISR-0004iE-ON for ram@iab.org; Mon, 19 Mar 2007 10:03:31 -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 1HTISD-0004Sv-It for ram@iab.org; Mon, 19 Mar 2007 10:03:31 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2JE3Gv7001603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Mar 2007 07:03:17 -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 l2JE3Gp8011270; Mon, 19 Mar 2007 07:03:16 -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 l2JE3Frb011250; Mon, 19 Mar 2007 07:03:16 -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); Mon, 19 Mar 2007 07:03:14 -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, 19 Mar 2007 07:03:13 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dns discover in map-and-encaps schemes Thread-Index: AcdqL1WMZ51EGL9HSDSSdZlBUWpr8w== From: "Templin, Fred L" To: "rrg" , X-OriginalArrivalTime: 19 Mar 2007 14:03:14.0308 (UTC) FILETIME=[560D7C40:01C76A2F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Subject: [RAM] dns discover in map-and-encaps schemes 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 the RRG meeting on Saturday, there may have been some confusion in what was meant by DNS discovery in map-and-encaps schemes. For DNS discovery, only locators are ever kept in the global DNS; identifiers are *not* kept in the global DNS but rather in a site-specific name resolution service for the site. From (IPvLX, Section 4): "4. DNS Assumptions The global DNS [RFC1035] today maintains resource records for Fully Qualified Domain Names (FQDNs) with global IPv4 addresses for traditional Internet services, and by design anticipates that their FQDN-to-address mappings will change relatively infrequently. IPvLX asks only that the global DNS also maintain resource records for IPvLX gateways to provide tunnel endpoint addresses - again, under the assumption that those FQDN-to-address mappings will change infrequently. IPvLX further assumes a DNS-like "site-local" name resolution service (e.g., [LLMNR]) that is separate from the global DNS and records the FQDN-to-IPv6-address mappings for IPv6 application endpoints within a site. Unlike the global DNS, IPvLX assumes that the FQDN-to-IPv6- address mappings within the site local name service may change dynamically as IPv6 application endpoints come into existence, move to new locations and terminate." This means that a source's address resolution request would trigger a lookup in the global DNS for the locator(s) associated with the destination's site, and a lookup for the destination's identifier in the destination site's name service. The following algorithm is used: 1) source does DNS lookup for the FQDN "dest.example.com". 2) source's DNS server is co-resident on the ingress tunnel router and performs a lookup in the global DNS for a well-known prefix appended to the FQDN suffix, e.g.: "egress.example.com". 3) source's DNS server gets back locators for the egress tunnel router from the global DNS, then sends an IP-in-IP encapsulated RFC4620 Node Information Query asking the egress tunnel router to resolve the FQDN "dest.example.com". 4) egress tunnel router returns identifers associated with "dest.example.com"; ingress tunnel router caches the resolution and returns the resolution to the source as response to the "real" DNS query. (The above algorithm omits the details of the tunnel setup btw the ingress and egress tunnel routers, but it should be clear that the tunnel is set up in parallel with the FQDN resolution.) Note that (IPvLX, Section 7) currently uses a different mechanism than RFC4620 because 4630 was not available at the time of the writing; I'll fix that. Note also that IPvLX fails to reference RFC1955; I'll fix that 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 Mon Mar 19 10:03: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 1HTISQ-0004ec-2b; Mon, 19 Mar 2007 10:03:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTISO-0004dy-8O for ram@iab.org; Mon, 19 Mar 2007 10:03:28 -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 1HTIS1-0004S2-Ch for ram@iab.org; Mon, 19 Mar 2007 10:03:28 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2JE32S6020883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Mar 2007 07:03:02 -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 l2JE31Tw015633; Mon, 19 Mar 2007 07:03:01 -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 l2JE2oYP015117; Mon, 19 Mar 2007 07:02:58 -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); Mon, 19 Mar 2007 07:02: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 Date: Mon, 19 Mar 2007 07:02:57 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747C1@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <45FE6CB4.9080104@info.ucl.ac.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: basic considerations for map-and-encaps schemes Thread-Index: AcdqFgL/sYrdMoseT+KkUU0+9htHBgADg+6A References: <45FE6CB4.9080104@info.ucl.ac.be> From: "Templin, Fred L" To: "rrg" , X-OriginalArrivalTime: 19 Mar 2007 14:02:58.0667 (UTC) FILETIME=[4CBADBB0:01C76A2F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [RAM] basic considerations for map-and-encaps schemes 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 see some of the map-and-encaps schemes being talked about as scratching the surface and in the early phases. I believe the following basic considerations should be addressed in any map-and-encaps scheme: 1) The locator address space and identifier address space need to be kept separate from the start. IPvLX already accomplishes this by using globally routable IPv4 addresses as locators and global IPv6 addresses as identifiers, i.e., the address spaces are kept separate. 2) Any map-and-encaps scheme will need to deal with the fact that IPv4 NATs are widely deployed and that is not likely to change in the near future. Therefore, the map-and-encaps scheme will need to deal with NAT traversal in the first iteration as IPvLX already does. 3) Since the tunnels created by map-and-encaps conceal an entire path within what appears as a single link to IP, path MTU assurance is necessary to avoid sending packets into a black hole over a link that cannot be diagnosed. A companion draft to IPvLX specifies a path MTU assurance mechanism for the ingress tunnel endpoint to get authenticated and reliable feedback from the egress tunnel enpoint. 4) The ingress/egress tunnel endpoints should be able to be located either in a network middlebox or on the source and/or destination end nodes themselves, e.g., when the end hosts also act as routers. IPvLX is flexible to allow for any and all deployment alternatives. 5) Sites that deploy a map-and-encaps scheme should implement an autoconfiguration scheme that allows end devices to configure identifiers, and routers to configure locators with little/no manual intervention. A companion draft to IPvLX specifies this function. These are just a few of the basic considerations that are already covered by IPvLX; the draft also discusses other considerations. Please review and comment on the draft (see: http://ipvlx.net). Fred fred.l.templin@boeing.com =20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 10:03: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 1HTISR-0004gc-BX; Mon, 19 Mar 2007 10:03:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTISQ-0004gC-Fc for ram@iab.org; Mon, 19 Mar 2007 10:03:30 -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 1HTIS9-0004Sd-PD for ram@iab.org; Mon, 19 Mar 2007 10:03:30 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2JE3D9Q001567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Mar 2007 07:03:13 -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 l2JE3CGn016085; Mon, 19 Mar 2007 07:03:12 -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 l2JE2vmC015461; Mon, 19 Mar 2007 07:03:08 -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); Mon, 19 Mar 2007 07:03:07 -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, 19 Mar 2007 07:03:07 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747C2@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: application endpoint identifiers in map-and-encaps schemes Thread-Index: AcdqL1F9G4MtI8q7QDS1jOp5zevu0w== From: "Templin, Fred L" To: "rrg" , X-OriginalArrivalTime: 19 Mar 2007 14:03:07.0636 (UTC) FILETIME=[52136B40:01C76A2F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [RAM] application endpoint identifiers in map-and-encaps schemes 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 During the RRG meeting on Saturday, Lixia presented a slide suggesting that not only locators and identifiers are desired, but also a possible separation in the identifer in terms of what the physical interface of the end node sees and what the *application endpoint* within the end node sees. I interpret this as follows: - let locators be assigned to the tunnel interfaces of ingress/egress tunnel routers - let *node* identifiers be assigned to the physical interfaces of end systems - let *application* identifiers be assigned to virtual interfaces (e.g., loopback interfaces) within end systems This could allow for the Ethernet-to-WiFi handoff Lixia referred to in her slide with no need to readdress the application endpoint identifiers, since only the node identifier changes. The following text from (IPvLX, Section 3) speaks to this: "3. Addressing and Routing Assumptions While IPv4 addresses in the current Internet are typically assigned to devices, IPvLX assumes that IPv6 addresses will also be assigned to application endpoints and data objects [NAME]. This new model would provide greater flexibility such that each end-node might host many different IPv6 application endpoints and data objects, and that those entities could migrate to other end-nodes. In this model, each IPv6 addressable entity would access other endpoints via an IPv6 router." Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 10:59: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 1HTJK5-0008B3-QB; Mon, 19 Mar 2007 10:58:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJK3-00086k-Hp for ram@ietf.org; Mon, 19 Mar 2007 10:58:55 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJJg-0006ss-Et for ram@ietf.org; Mon, 19 Mar 2007 10:58:55 -0400 Received: from [IPv6:2001:df8::48:20a:95ff:fecd:987a] ([IPv6:2001:df8:0:48:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2JEvafp098501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2007 15:57:38 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85413D82-CCE5-44AA-85B5-E5712C3E723B@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Mon, 19 Mar 2007 15:57:57 +0100 To: ram@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-0.9 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: 538aad3a3c4f01d8b6a6477ca4248793 Cc: massey@cs.colostate.edu Subject: [RAM] Geographic addressing 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 [directed to the RAM list with CCs to the draft authors, please trim on followups as necessary] I just read draft-wang-ietf-efit-00.txt, which mentions: 6.2. Location-Based Addressing Another way to allocate addresses in an aggregatable manner is to base the allocation on locations, which was proposed by Deering in early 90's [MetroAddr]. This approach can avoid user renumbering when they change providers, as long as they stay in the same location. More recently a similar proposal, Geo-based addressing [GeoAddr] has been made. Although this proposal has certain differences from [MetroAddr], for example encoding latitude and longitude information into the address instead of metro-area ID, the two proposals bear fundamental similarities. They are both proposed as one of the ways, but not necessarily the only way, to allocate IPv6 addresses, both envisioned coexistence of location-based and provider-based addresses, and which type to use would be based on the need of individual parties. However location-based addressing imposes two infeasible conditions to the routing system. First, routing over location-based addresses requires that ISPs interconnect at each location. Second, location- based addresses do not reflect interconnectivity among providers to enable routing policies. Although the specifics of the proposals that are cited may impose new requirements on on the topology of ISP networks, this doesn't necessarily follow from geographic addressing in general. A few years ago I wrote this draft: http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt The idea here is that each AS holds a full view of the entire default- free zone, but rather than giving each individual BGP router within the AS a full copy of the DFZ, each router only handles part of the DFZ. This means packets must first be forwarded to the place where the routing information for the destination address is known, and then they are forwarded to their destination. This is the basic idea of increased stretch routing. However, if we can locate the routers that hold the routing information for a certain part of the address space close to the place where that address space is used, there may not be any detours to speak of in practice, avoiding the down side of increased stretch routing. In the event that there is no interconnection in the area where the addresses are used, aggregation breaks or detours happen, but as long as this is for a relatively small fraction of prefixes/packets, that shouldn't be a problem. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 11:14: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 1HTJWq-0002jI-HI; Mon, 19 Mar 2007 11:12:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJWp-0002j8-Gx for ram@iab.org; Mon, 19 Mar 2007 11:12:07 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJWo-0001W7-P0 for ram@iab.org; Mon, 19 Mar 2007 11:12:07 -0400 Received: from [IPv6:2001:df8::48:20a:95ff:fecd:987a] ([IPv6:2001:df8:0:48:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2JFBi9E098875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2007 16:11:44 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <45FC10FD.2060507@piuha.net> References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on Date: Mon, 19 Mar 2007 16:12:05 +0100 To: Jari Arkko X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.2 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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 17-mrt-2007, at 17:02, Jari Arkko wrote: >> What I'm thinking of here is increasing the average size of IP >> packets, because the bad stuff, such as the number of FIB lookups >> required, typically scales at O(#packets) while the good stuff >> typically scales at O(bandwidth). > I am all for increasing the average size of packets. But I'll note > that > its probably not a panacea. Router cost, for instance, is a function > of many factors, including FIB looks, filtering, fancy prioritizing > schemes as well as line speed. And Path MTU increase is one of those > nasty things where the weakest link counts, so getting that deployed > requires updates in several places. But yes, I think it would still > be useful. Yes, there are many reasons why this is and has been a low-return investment. However, we're rapidly approaching the situation where, for a significant number of paths, at every hop, the hardware supports packet sizes larger than 1500 bytes, but we have no reasonable way of using this capability where it exists. But if we can make things such that the largest packets possible are used, over time, more and more packets will be larger than 1500 bytes so the growth in the total amount of per-packet work will start to trail the growth in bandwidth. Over time, the savings in processing power / energy use will become more and more significant. I guess I have a draft to write. :-) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 11:22:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJgY-0002A0-5I; Mon, 19 Mar 2007 11:22:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJgX-00029q-On for ram@iab.org; Mon, 19 Mar 2007 11:22:09 -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 1HTJgV-0003Er-BB for ram@iab.org; Mon, 19 Mar 2007 11:22:09 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l2JFLtX4003691; Mon, 19 Mar 2007 17:21:55 +0200 Date: Mon, 19 Mar 2007 17:21:55 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on In-Reply-To: <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> Message-ID: References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.1/2869/Mon Mar 19 03:41:00 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS, TW_JN 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: 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 On Mon, 19 Mar 2007, Iljitsch van Beijnum wrote: > Yes, there are many reasons why this is and has been a low-return > investment. However, we're rapidly approaching the situation where, > for a significant number of paths, at every hop, the hardware > supports packet sizes larger than 1500 bytes, but we have no > reasonable way of using this capability where it exists. ... IMHO, the bigger problem is that if we end up with any kind of solution that employs encapsulation, we end up in a potentially nasty mess of PMTUD issues unless we're able to raise the MTU on links between the encapsulators and decapsulators. The pain is felt worst in Ethernet-based (all of them? :-) exchange points due to the lowest common denominator MTU. (Some IXs have tried to create separate, optional "big MTU VLANs" but I don't think those have been very popular). On direct peerings from the technology and O&M perspective, usually raising MTU is possible. -- 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 Mon Mar 19 11:24: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 1HTJiF-0002Yl-Hb; Mon, 19 Mar 2007 11:23:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJiE-0002Yd-Gy for ram@iab.org; Mon, 19 Mar 2007 11:23:54 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJiD-0003Tt-2y for ram@iab.org; Mon, 19 Mar 2007 11:23:54 -0400 Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 19 Mar 2007 08:23:43 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 3D4DB2AF; Mon, 19 Mar 2007 08:23:43 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 2944E2AE; Mon, 19 Mar 2007 08:23:43 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBV37896; Mon, 19 Mar 2007 08:23:38 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id F411920501; Mon, 19 Mar 2007 08:23:37 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RAM] what we should be working on Date: Mon, 19 Mar 2007 08:23:35 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A410342870D@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> Thread-Topic: [RAM] what we should be working on Thread-Index: AcdqOVTdZ/pvMn6aQOiHSJYqsMrOdwAAFz8w From: "Puneet Agarwal" To: "Iljitsch van Beijnum" , "Jari Arkko" X-WSS-ID: 69E075753A45439677-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Iljitsch, Lookup bandwidth is dominated by small packets (all the TCP acks that are flowing). Increasing the MTU to be > 1500 will not solve the lookup bandwidth problem. Almost 50% of all packets are 64 bytes (on Ethernet) and a little smaller over PPP. Hence increased MTU (greater than 1500) will not solve the lookup bw problem. Thanks. -Puneet -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 Sent: Monday, March 19, 2007 8:12 AM To: Jari Arkko Cc: ram@iab.org Subject: Re: [RAM] what we should be working on On 17-mrt-2007, at 17:02, Jari Arkko wrote: >> What I'm thinking of here is increasing the average size of IP=20 >> packets, because the bad stuff, such as the number of FIB lookups=20 >> required, typically scales at O(#packets) while the good stuff=20 >> typically scales at O(bandwidth). > I am all for increasing the average size of packets. But I'll note=20 > that its probably not a panacea. Router cost, for instance, is a=20 > function of many factors, including FIB looks, filtering, fancy=20 > prioritizing schemes as well as line speed. And Path MTU increase is=20 > one of those nasty things where the weakest link counts, so getting=20 > that deployed requires updates in several places. But yes, I think it=20 > would still be useful. Yes, there are many reasons why this is and has been a low-return investment. However, we're rapidly approaching the situation where, for a significant number of paths, at every hop, the hardware supports packet sizes larger than 1500 bytes, but we have no reasonable way of using this capability where it exists. But if we can make things such that the largest packets possible are used, over time, more and more packets will be larger than 1500 bytes so the growth in the total amount of per-packet work will start to trail the growth in bandwidth. Over time, the savings in processing power / energy use will become more and more significant. I guess I have a draft to write. :-) _______________________________________________ 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 Mar 19 11:36:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJtF-0002V7-QF; Mon, 19 Mar 2007 11:35:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJtD-0002Ur-Sr; Mon, 19 Mar 2007 11:35:15 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJt6-0005Ca-Lu; Mon, 19 Mar 2007 11:35:15 -0400 Received: from [IPv6:2001:df8::48:20a:95ff:fecd:987a] ([IPv6:2001:df8:0:48:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2JFYg86099324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2007 16:34:44 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5ECD510F-FA7A-486E-99D1-935B017E0FE9@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: full IPv6 transition, was: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Mon, 19 Mar 2007 16:35:03 +0100 To: Pekka Savola X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00, ILJQX_SUBJ_NUMINWORD 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: 82c9bddb247d9ba4471160a9a865a5f3 Cc: iab@ietf.org, Noel Chiappa , 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 18-mrt-2007, at 19:50, Pekka Savola wrote: > First of all, what do you (and the draft) mean with 'full IPv6 > transition'? The scenario where IPv4 has been shut off, or dual- > stack everywhere? In any case this probably needs to be clarified. I can't speak for the draft or its authors, but my definition is as follows: Currently, the assumption is that every resource connected to the internet is reachable over IPv4, and it may or may not be reachable over IPv6. The point of interest on the line between the situation we have today and the one where there are no longer any IPv4 systems is the point where the assumption is that every resource is available over IPv6, and optionally over IPv4. I.e., the day that the IPv6-only people turn off the gateways they use to reach the legacy IPv4 internet. > Especially if you mean 'everyone is using v6', I'm skeptical of > these statements. Could someone give some ideas what exactly would > contribute the IPv6 prefix count? I've trouble figuring how to get > to even 100K prefixes (transforming the _current_ v4 routing table > to v6; in 2050 the situation is likely different :-). > The key point with IPv6 at the moment is that instead of an ISP > having to have 100 identically-routed, non-contiguous prefixes, it > could have just one or a couple of them. End-sites also often have > non-contiguous prefixes which wouldn't (by routing policy) need to > be deaggregated. If you telnet to route-views.oregon-ix.net and type "show ip bgp regexp _6461_1103$" you'll see the list of prefixes announced by Surfnet, the Dutch academic network. It's a very long list. It used to be much shorter: a number of years ago, they announced 145.0.0.0/9 (IIRC) but now they announce all the class B blocks falling within that more or less individually. Apparently, so many of these blocks have moved away that announcing the aggregate no longer made sense. These same issues will be present in IPv6 when it gets widely deployed. However, the question is open as to how much deaggregation the community will allow. In IPv4, /24 is as long as prefixes get. Currently, many people filter on /32 in IPv6, which may or may not persist in the future. But I don't think the community at large will accept arbitrary /48s, because there are / can be so many of them: it only takes a few /32s deaggregated into /48s to melt down your router. I got heckled in (I think) the IEPG meeting when someone said the prefixes WILL be announced and I said they WILL be filtered. Sure, you can pay an ISP to carry more specifics. But you can't pay them all. Also, in IPv6 you can filter with relative impunity because it doesn't really break connectivity with IPv4 to fall back on. How large the IPv6 table will be in the future is anyone's guess, but I'm pretty sure simply extrapolating IPv4 figures won't get us very close. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 11:49:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTK57-0000Id-DF; Mon, 19 Mar 2007 11:47:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTK56-0000I0-DY for ram@iab.org; Mon, 19 Mar 2007 11:47:32 -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 1HTK4O-0006xA-JI for ram@iab.org; Mon, 19 Mar 2007 11:47:32 -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 l2JFkZmh004765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Mar 2007 10:46:36 -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 l2JFkZGd011154; Mon, 19 Mar 2007 08:46:35 -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 l2JFkY8k011107; Mon, 19 Mar 2007 08:46:35 -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); Mon, 19 Mar 2007 08:46: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] what we should be working on Date: Mon, 19 Mar 2007 08:46:34 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747C8@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] what we should be working on Thread-Index: AcdqOU2PP6zgX1FDRvm5r6lXiEGOCAABEtMg References: <45F94921.7010707@piuha.net><45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> From: "Templin, Fred L" To: "Iljitsch van Beijnum" , "Jari Arkko" X-OriginalArrivalTime: 19 Mar 2007 15:46:35.0106 (UTC) FILETIME=[C6042C20:01C76A3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 guess I have a draft to write. :-) And the problem with *my* draft is... ?? http://ipvlx.net Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 11:52: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 1HTKA3-00055z-R4; Mon, 19 Mar 2007 11:52:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKA1-00052l-A2 for ram@iab.org; Mon, 19 Mar 2007 11:52:37 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTK9P-0007bU-J0 for ram@iab.org; Mon, 19 Mar 2007 11:52:37 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 24A8D198690; Mon, 19 Mar 2007 17:51:56 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 49D0C19867C; Mon, 19 Mar 2007 17:51:55 +0200 (EET) Message-ID: <45FEB19A.9040104@piuha.net> Date: Mon, 19 Mar 2007 16:51:54 +0100 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on References: <45F94921.7010707@piuha.net><45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747C8@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747C8@XCH-NW-7V2.nw.nos.boeing.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: d17f825e43c9aed4fd65b7edddddec89 Cc: "Templin, Fred L" , 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, >> I guess I have a draft to write. :-) >> Do you actually need to write something? Seems like we have the technology (unless want to modify TCP ACKs) to do what we need... it might be more useful to go and configure a few exchange points to bigger MTU... Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 11:52: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 1HTK9U-0004xc-GS; Mon, 19 Mar 2007 11:52:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTK9T-0004xH-Pc; Mon, 19 Mar 2007 11:52:03 -0400 Received: from owl.ecs.soton.ac.uk ([152.78.68.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTK8n-0006YX-Mz; Mon, 19 Mar 2007 11:52:03 -0400 Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [152.78.68.131]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id l2JFp4mc032116; Mon, 19 Mar 2007 15:51:04 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id l2JFoqve012997; Mon, 19 Mar 2007 15:50:52 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id l2JFopOY030011; Mon, 19 Mar 2007 15:50:51 GMT Date: Mon, 19 Mar 2007 15:50:51 +0000 From: Tim Chown To: iab@ietf.org, ram@iab.org Subject: Re: full IPv6 transition, was: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Message-ID: <20070319155051.GJ27293@login.ecs.soton.ac.uk> References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> <5ECD510F-FA7A-486E-99D1-935B017E0FE9@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ECD510F-FA7A-486E-99D1-935B017E0FE9@muada.com> User-Agent: Mutt/1.4i X-Null-Tag: 8ae10e02ba85e7601f8c682b58d65f56 X-Null-Tag: 10e18437e14fbfe5b58c33e5cbb53777 X-ECS-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 On Mon, Mar 19, 2007 at 04:35:03PM +0100, Iljitsch van Beijnum wrote: > > Currently, the assumption is that every resource connected to the > internet is reachable over IPv4, and it may or may not be reachable > over IPv6. The point of interest on the line between the situation we > have today and the one where there are no longer any IPv4 systems is > the point where the assumption is that every resource is available > over IPv6, and optionally over IPv4. I think this view or question needn't be correct. It's quite possible that new application domains (e.g. peer-to-peer or those where the servers are mobile or in SOHO networks) will use IPv6, while users quite merrily (including web browsing for example). > I got heckled in (I think) the IEPG meeting when someone said the > prefixes WILL be announced and I said they WILL be filtered. Sure, > you can pay an ISP to carry more specifics. But you can't pay them > all. Also, in IPv6 you can filter with relative impunity because it > doesn't really break connectivity with IPv4 to fall back on. I met Marc Blancet this morning. He has IPv6 PI, and is now having fun seeing where his /48 is seen :) -- Tim _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 11:52: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 1HTKA3-00055z-R4; Mon, 19 Mar 2007 11:52:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKA1-00052l-A2 for ram@iab.org; Mon, 19 Mar 2007 11:52:37 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTK9P-0007bU-J0 for ram@iab.org; Mon, 19 Mar 2007 11:52:37 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 24A8D198690; Mon, 19 Mar 2007 17:51:56 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 49D0C19867C; Mon, 19 Mar 2007 17:51:55 +0200 (EET) Message-ID: <45FEB19A.9040104@piuha.net> Date: Mon, 19 Mar 2007 16:51:54 +0100 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on References: <45F94921.7010707@piuha.net><45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747C8@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747C8@XCH-NW-7V2.nw.nos.boeing.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: d17f825e43c9aed4fd65b7edddddec89 Cc: "Templin, Fred L" , 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, >> I guess I have a draft to write. :-) >> Do you actually need to write something? Seems like we have the technology (unless want to modify TCP ACKs) to do what we need... it might be more useful to go and configure a few exchange points to bigger MTU... Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 11:52: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 1HTK9U-0004xc-GS; Mon, 19 Mar 2007 11:52:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTK9T-0004xH-Pc; Mon, 19 Mar 2007 11:52:03 -0400 Received: from owl.ecs.soton.ac.uk ([152.78.68.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTK8n-0006YX-Mz; Mon, 19 Mar 2007 11:52:03 -0400 Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [152.78.68.131]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id l2JFp4mc032116; Mon, 19 Mar 2007 15:51:04 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id l2JFoqve012997; Mon, 19 Mar 2007 15:50:52 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id l2JFopOY030011; Mon, 19 Mar 2007 15:50:51 GMT Date: Mon, 19 Mar 2007 15:50:51 +0000 From: Tim Chown To: iab@ietf.org, ram@iab.org Subject: Re: full IPv6 transition, was: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Message-ID: <20070319155051.GJ27293@login.ecs.soton.ac.uk> References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> <5ECD510F-FA7A-486E-99D1-935B017E0FE9@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ECD510F-FA7A-486E-99D1-935B017E0FE9@muada.com> User-Agent: Mutt/1.4i X-Null-Tag: 8ae10e02ba85e7601f8c682b58d65f56 X-Null-Tag: 10e18437e14fbfe5b58c33e5cbb53777 X-ECS-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 On Mon, Mar 19, 2007 at 04:35:03PM +0100, Iljitsch van Beijnum wrote: > > Currently, the assumption is that every resource connected to the > internet is reachable over IPv4, and it may or may not be reachable > over IPv6. The point of interest on the line between the situation we > have today and the one where there are no longer any IPv4 systems is > the point where the assumption is that every resource is available > over IPv6, and optionally over IPv4. I think this view or question needn't be correct. It's quite possible that new application domains (e.g. peer-to-peer or those where the servers are mobile or in SOHO networks) will use IPv6, while users quite merrily (including web browsing for example). > I got heckled in (I think) the IEPG meeting when someone said the > prefixes WILL be announced and I said they WILL be filtered. Sure, > you can pay an ISP to carry more specifics. But you can't pay them > all. Also, in IPv6 you can filter with relative impunity because it > doesn't really break connectivity with IPv4 to fall back on. I met Marc Blancet this morning. He has IPv6 PI, and is now having fun seeing where his /48 is seen :) -- Tim _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 11:55: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 1HTKC8-0005o9-JV; Mon, 19 Mar 2007 11:54:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKC7-0005o4-K6 for ram@iab.org; Mon, 19 Mar 2007 11:54:47 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTKC6-0007IL-4r for ram@iab.org; Mon, 19 Mar 2007 11:54:47 -0400 Received: from [IPv6:2001:df8::48:20a:95ff:fecd:987a] ([IPv6:2001:df8:0:48:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2JFsAwm099678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2007 16:54:10 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <8954613CA6BB3242A1531D916A527A410342870D@NT-SJCA-0751.brcm.ad.broadcom.com> References: <8954613CA6BB3242A1531D916A527A410342870D@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CE4F14A-A065-4911-A888-E00FD33B457D@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on Date: Mon, 19 Mar 2007 16:54:31 +0100 To: "Puneet Agarwal" X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.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: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 19-mrt-2007, at 16:23, Puneet Agarwal wrote: > Lookup bandwidth is dominated by small packets (all the TCP acks that > are flowing). Increasing the MTU to be > 1500 will not solve the > lookup > bandwidth problem. Almost 50% of all packets are 64 bytes (on > Ethernet) > and a little smaller over PPP. > Hence increased MTU (greater than 1500) will not solve the lookup bw > problem. Not sure what you mean by "solve". General purpose computers almost always use less power when idle than when doing work. If this is true for routers doing FIB lookups (not a given, but I don't see how it would be possible to authoritatively say it can NEVER be true in the future) then having fewer packets for a given amount of bandwidth is helpful. Obviously there are applications that generate small packets, so a larger MTU won't make those packets larger. But for TCP it does help. If you have to send 100 packets with 1500 byte packets but only 20 with large packets, this means that the number of TCP ACKs will go down from approximately 50 to approximately 10 and the total from 150 to 30. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 11:58: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 1HTKFa-0007no-EH; Mon, 19 Mar 2007 11:58:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKFZ-0007mU-5U for ram@iab.org; Mon, 19 Mar 2007 11:58:21 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTKFO-0008KR-PQ for ram@iab.org; Mon, 19 Mar 2007 11:58:21 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2JFvw6a012180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Mar 2007 08:57:58 -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 l2JFvwtM008681; Mon, 19 Mar 2007 08:57:58 -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 l2JFvsnv008495; Mon, 19 Mar 2007 08:57:58 -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); Mon, 19 Mar 2007 08:57:56 -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] what we should be working on Date: Mon, 19 Mar 2007 08:57:55 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747CA@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <45FEB19A.9040104@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] what we should be working on Thread-Index: AcdqPog0F53pT2OmTvKI1hAiOPoKsgAACmWQ References: <45F94921.7010707@piuha.net><45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747C8@XCH-NW-7V2.nw.nos.boeing.com> <45FEB19A.9040104@piuha.net> From: "Templin, Fred L" To: "Jari Arkko" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 19 Mar 2007 15:57:56.0755 (UTC) FILETIME=[5C4F8E30:01C76A3F] X-Spam-Score: 0.0 (/) 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 > Do you actually need to write something? Seems like we > have the technology (unless want to modify TCP ACKs) to > do what we need... it might be more useful to go and > configure a few exchange points to bigger MTU... Are you meaning the work that came out of the PMTUD wg? That is good for discovering the optimum MTU over the entire path, but it doesn't help to discover the optimum MTU from *within the tunnel*. The tunnel is just an ordinary link, and may be only a single hop on the path btw the TCP endpoints, but the tunnel ingress needs to discover and enforce an optimum MTU from within if the TCPs are ever going to take advantage of the larger MTUs. Fred fred.l.templin@boeing.com=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 12:11: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 1HTKQu-0004vY-Dw; Mon, 19 Mar 2007 12:10:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKQs-0004vB-6S for ram@iab.org; Mon, 19 Mar 2007 12:10:02 -0400 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTKQl-0001xU-Ek for ram@iab.org; Mon, 19 Mar 2007 12:10:02 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id E1892341E9; Mon, 19 Mar 2007 12:09:49 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 12:09:42 -0400 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] Architectural comments on draft-farinacci-lisp-00 Date: Mon, 19 Mar 2007 12:09:40 -0400 Message-ID: <816DD9299957E547B5D758D7F977D6DC01A03A2F@tayexc14.americas.cpqcorp.net> In-Reply-To: <45FE6DF4.20303@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Architectural comments on draft-farinacci-lisp-00 Thread-Index: AcdqFkXspGQn/2aZSgeKvNgf4HhIUAAKiQyQ References: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> <816DD9299957E547B5D758D7F977D6DC0179E968@tayexc14.americas.cpqcorp.net> <816DD9299957E547B5D758D7F977D6DC019B2A6C@tayexc14.americas.cpqcorp.net> <45FE6DF4.20303@piuha.net> From: "Bound, Jim" To: "Jari Arkko" , "Pekka Nikander" X-OriginalArrivalTime: 19 Mar 2007 16:09:42.0986 (UTC) FILETIME=[0141DAA0:01C76A41] 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 Well I cannot imagine any presentation that will move us forward as LISP is trying too. The bottom line is there is no way to do loc/id split with current software/hardware implementations that can be deployed in less than 5 years, the LISP proposal and prototyping already being discussed with some implementers here, myself included, could give us that solution in 2 years with initial deployment at the edges. I see no alternative but baby steps towards a solution to RAWs report. I have still not seen a good answer to Brian Carpenter's questions on the use and requirement for split loc/id that would not be an IRTF effort. The entire notion is up for debate regarding split id/loc in my view. =20 Are we also having a presentation the supports the LISP proposal in addition to Pekka N's clear biased view (this is not a negative comment just a fact). /jim > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Monday, March 19, 2007 7:03 AM > To: Pekka Nikander > Cc: Bound, Jim; ram@iab.org > Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 >=20 > Pekka, Jim, > > You may well be right that not going for id/loc split but doing=20 > > something like LISP (or rather eFIT,=20 > draft-wang-ietf-efit-00.txt) may=20 > > be a better way to address the immediate RAWs problem space. > > > > OTOH, I think some rudimentary sort of id/loc split would be soon=20 > > ready for wide deployment, if people decide to take the=20 > effort. That=20 > > is, we are not quite there yet, but not that far either, IMHO. > > > > A large open question, IMHO, is whether we should aim for BOTH=20 > > separating core routing from the edge addresses (a la eFit) AND the=20 > > edge addresses from host identifiers, or aim for a combined=20 > approach. > > That'll be main my point on my very brief INT area presentation on=20 > > Thursday. >=20 > Yes, this is one of the big questions I would like to get an=20 > answer to. > FWIW, I think there's something to be said for a=20 > modularization and making focused solutions to specific=20 > problems. But if we do that then we need to be very clear=20 > that it is indeed a solution for a very specific problem, not=20 > the grand tool to get rid of all the pain caused by the dual=20 > role of addresses. OTOH, some of the drafts seem to say that=20 > a more complete solution would also be possible. > If that can be done without unreasonable difficulties, it=20 > should of course be preferred. I don't have a good sense yet=20 > on how easy or hard that would be. I'm hoping Pekka's=20 > presentation on Thursday will provide some light on that. >=20 > Jari >=20 >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 12:15: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 1HTKUV-0006Rw-AZ; Mon, 19 Mar 2007 12:13:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKUR-0006Q4-UV for ram@iab.org; Mon, 19 Mar 2007 12:13:44 -0400 Received: from purgatory.unfix.org ([213.136.24.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTKUN-0002Dg-E3 for ram@iab.org; Mon, 19 Mar 2007 12:13:43 -0400 Received: from [IPv6:2001:770:100:9e::2] (cl-159.dub-01.ie.sixxs.net [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id 371B4140C1A9; Mon, 19 Mar 2007 17:13:08 +0100 (CET) Message-ID: <45FEB698.20401@spaghetti.zurich.ibm.com> Date: Mon, 19 Mar 2007 16:13:12 +0000 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Tim Chown Subject: Re: full IPv6 transition, was: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> <5ECD510F-FA7A-486E-99D1-935B017E0FE9@muada.com> <20070319155051.GJ27293@login.ecs.soton.ac.uk> In-Reply-To: <20070319155051.GJ27293@login.ecs.soton.ac.uk> X-Enigmail-Version: 0.94.3.0 OpenPGP: id=333E7C23 X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=ham version=3.1.7-deb X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on purgatory.unfix.org X-Virus-Scanned: ClamAV 0.90.1/2872/Mon Mar 19 11:31:47 2007 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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="===============0354390702==" Errors-To: ram-bounces@iab.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0354390702== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2686A82DCD92CA3C87EF4F15" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2686A82DCD92CA3C87EF4F15 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [stripped iab from the list, don't think they need more of my spam ;) ] Tim Chown wrote: [..] >> I got heckled in (I think) the IEPG meeting when someone said the =20 >> prefixes WILL be announced and I said they WILL be filtered. Sure, =20 >> you can pay an ISP to carry more specifics. But you can't pay them =20 >> all. Also, in IPv6 you can filter with relative impunity because it =20 >> doesn't really break connectivity with IPv4 to fall back on. >=20 > I met Marc Blancet this morning. He has IPv6 PI, and is now having fun= > seeing where his /48 is seen :) According to: http://www.sixxs.net/tools/grh/dfp/arin/ it (2620:0:230::/48) is being seen by 63% of the GRH participants. 2620:0:c0::/48 is at 83% And it is very easy to see, by following the LG link, which ISP's are filtering it out. A couple of the larger transits are still filtering it though, but it won't take too long before that is resolved. Greets, Jeroen (who just bugged the ipv6-ops list to resolve the rest of the filters :) --------------enig2686A82DCD92CA3C87EF4F15 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkX+tpguFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I1+dAJ4g7NIH6LJaF9nIMgXpp9GjCaKP MgCgr5WeK7pDHBaV8Byx8k3rAm2/DGc= =0mzh -----END PGP SIGNATURE----- --------------enig2686A82DCD92CA3C87EF4F15-- --===============0354390702== 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 --===============0354390702==-- From ram-bounces@iab.org Mon Mar 19 12:16: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 1HTKWq-0001ug-QX; Mon, 19 Mar 2007 12:16:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKWq-0001uZ-7G for ram@iab.org; Mon, 19 Mar 2007 12:16:12 -0400 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTKWl-0003Or-Hd for ram@iab.org; Mon, 19 Mar 2007 12:16:12 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 0E72834194; Mon, 19 Mar 2007 12:16:04 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 12:12:28 -0400 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] Re: Impending publication: draft-iab-raws-report-01.txt Date: Mon, 19 Mar 2007 12:12:26 -0400 Message-ID: <816DD9299957E547B5D758D7F977D6DC01A03A33@tayexc14.americas.cpqcorp.net> In-Reply-To: <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Thread-Index: AcdqJBYqAbtWgQymQSOoUhMdmgOcYQAHQdmw References: <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> From: "Bound, Jim" To: "Ross Callon" , "Yakov Rekhter" , "Lixia Zhang" X-OriginalArrivalTime: 19 Mar 2007 16:12:28.0797 (UTC) FILETIME=[64169AD0:01C76A41] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: iab@ietf.org, 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 Clearly we need consensus on this report and where we as a collective body do not believe the report accurate. If it just one section then lets fix it if people believe the entire report is bugged-out then please say that here. I do believe some enhancements need to be made for clarity around the routing nomenclature and statements regarding microprocessor deployment claims for sure, but other than that I think the document is pretty much spot on. =20 /jim=20 > -----Original Message----- > From: Ross Callon [mailto:rcallon@juniper.net]=20 > Sent: Monday, March 19, 2007 8:40 AM > To: Yakov Rekhter; Lixia Zhang > Cc: iab@ietf.org; ram@iab.org > Subject: Re: [RAM] Re: Impending publication:=20 > draft-iab-raws-report-01.txt=20 >=20 > At 10:03 PM 3/18/2007 -0700, Yakov Rekhter wrote: > >... > >I do not think Tony's suggestion is sufficient. The document=20 > needs to=20 > >clearly spell out the implications of using RLDRAM instead of DRAM.=20 > >Specifically, whether the document conclusions still hold=20 > even if one=20 > >uses RLDRAM. > > > >Yakov. >=20 > To me it seems like our understanding of the problem, and of=20 > potential solutions, continues to evolve over time=20 > (particularly as we look into the details more closely). As=20 > one example, I personally was not aware of the distinction=20 > between RLDRAM and regular DRAM when in Amsterdam, nor was=20 > this difference discussed in Amsterdam, but I have learned=20 > about this since returning from the workshop. >=20 > This leads to a question: To what extent is the workshop=20 > report supposed to be an accurate description of what went on=20 > at the workshop, and to what extent is it supposed to be an=20 > accurate description of what we *now* feel is the problem and=20 > range of possible solutions? I haven't sent in detailed=20 > comment on the report because I think that it is an accurate=20 > description of what was discussed at the time in Amsterdam,=20 > and also because I don't think that our understanding of the=20 > problem will become static for quite a while (so if the=20 > document needs to reflect current improved understanding, it=20 > won't be fully stable for quite a while). >=20 > The document's abstract states: >=20 > This document reports the outcome of the Routing and Addressing > Workshop which the Internet Architecture Board (IAB) held on > October 18-19, 2006 in Amsterdam, Netherlands. > ... > Note that this document is a report on the proceedings of the > workshop. The views and positions documented in this report are > those of the workshop participants and not the IAB. >=20 > According to the first sentence of the abstract I would not=20 > expect the document to be an accurate description of the more=20 > detailed or more precise work that has gone on since the=20 > workshop, nor an accurate reflection of the greater level of=20 > understanding that has occurred since (which to me appears to=20 > still have a long way to go). > In fact, the last sentence is not quite right, since the=20 > views and positions documented in the report are those that=20 > were stated by workshop participants at the time, and do not=20 > necessarily reflect the *current* views of at least some of=20 > the workshop participants. >=20 > Perhaps we should add an additional sentence to either the=20 > abstract or to the last paragraph of section 1 that says: >=20 > Work on issues related to this workshop report is continuing, > and this document does not intend to accurately reflect the > increased understanding of issues nor to discuss the range of > potential solutions that may be the outcome of this=20 > ongoing work. >=20 > Ross >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 12:23:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKdc-0000BV-VF; Mon, 19 Mar 2007 12:23:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKdb-0000BO-Qp for ram@iab.org; Mon, 19 Mar 2007 12:23:11 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTKda-0004OL-IU for ram@iab.org; Mon, 19 Mar 2007 12:23:11 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B65D8198690; Mon, 19 Mar 2007 18:23:09 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 59980198683; Mon, 19 Mar 2007 18:23:09 +0200 (EET) Message-ID: <45FEB8EC.8000408@piuha.net> Date: Mon, 19 Mar 2007 17:23:08 +0100 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: "Bound, Jim" Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 References: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> <816DD9299957E547B5D758D7F977D6DC0179E968@tayexc14.americas.cpqcorp.net> <816DD9299957E547B5D758D7F977D6DC019B2A6C@tayexc14.americas.cpqcorp.net> <45FE6DF4.20303@piuha.net> <816DD9299957E547B5D758D7F977D6DC01A03A2F@tayexc14.americas.cpqcorp.net> In-Reply-To: <816DD9299957E547B5D758D7F977D6DC01A03A2F@tayexc14.americas.cpqcorp.net> 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: 7bac9cb154eb5790ae3b2913587a40de Cc: Pekka Nikander , 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 Ward will be talking about requirements from a routing system / deployment point of view, and I believe this is largely going to be based on Dino's material. And this in turn, was the rationale behind LISP. I am very much in agreement with you that we need a deployable scheme. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 12:23:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKdR-0008Uk-F7; Mon, 19 Mar 2007 12:23:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKdQ-0008Uf-GM for ram@iab.org; Mon, 19 Mar 2007 12:23:00 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTKdP-0004L7-1w for ram@iab.org; Mon, 19 Mar 2007 12:23:00 -0400 Received: from [IPv6:2001:df8::16:20a:95ff:fef5:246e] ([IPv6:2001:df8:0:16:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2JGMXd2000489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2007 17:22:34 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747C8@XCH-NW-7V2.nw.nos.boeing.com> References: <45F94921.7010707@piuha.net><45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> From ram-bounces@iab.org Mon Mar 19 12:23:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKdc-0000BV-VF; Mon, 19 Mar 2007 12:23:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKdb-0000BO-Qp for ram@iab.org; Mon, 19 Mar 2007 12:23:11 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTKda-0004OL-IU for ram@iab.org; Mon, 19 Mar 2007 12:23:11 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B65D8198690; Mon, 19 Mar 2007 18:23:09 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 59980198683; Mon, 19 Mar 2007 18:23:09 +0200 (EET) Message-ID: <45FEB8EC.8000408@piuha.net> Date: Mon, 19 Mar 2007 17:23:08 +0100 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: "Bound, Jim" Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 References: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> <816DD9299957E547B5D758D7F977D6DC0179E968@tayexc14.americas.cpqcorp.net> <816DD9299957E547B5D758D7F977D6DC019B2A6C@tayexc14.americas.cpqcorp.net> <45FE6DF4.20303@piuha.net> <816DD9299957E547B5D758D7F977D6DC01A03A2F@tayexc14.americas.cpqcorp.net> In-Reply-To: <816DD9299957E547B5D758D7F977D6DC01A03A2F@tayexc14.americas.cpqcorp.net> 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: 7bac9cb154eb5790ae3b2913587a40de Cc: Pekka Nikander , 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 Ward will be talking about requirements from a routing system / deployment point of view, and I believe this is largely going to be based on Dino's material. And this in turn, was the rationale behind LISP. I am very much in agreement with you that we need a deployable scheme. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 12:23:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKdR-0008Uk-F7; Mon, 19 Mar 2007 12:23:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKdQ-0008Uf-GM for ram@iab.org; Mon, 19 Mar 2007 12:23:00 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTKdP-0004L7-1w for ram@iab.org; Mon, 19 Mar 2007 12:23:00 -0400 Received: from [IPv6:2001:df8::16:20a:95ff:fef5:246e] ([IPv6:2001:df8:0:16:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2JGMXd2000489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2007 17:22:34 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747C8@XCH-NW-7V2.nw.nos.boeing.com> References: <45F94921.7010707@piuha.net><45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747C8@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F49223B-1D88-4A1C-967C-F87DD56C7FBA@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on Date: Mon, 19 Mar 2007 17:22:55 +0100 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=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: 1ac7cc0a4cd376402b85bc1961a86ac2 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 19-mrt-2007, at 16:46, Templin, Fred L wrote: >> I guess I have a draft to write. :-) > And the problem with *my* draft is... ?? That (from a quick scan) it doesn't actually make it possible to have systems with different MTUs on the same subnet? Have a look at the discussion under "Re: jumbo frame of GbE and IPv6 -- A proposal" on http://www1.ietf.org/mail-archive/web/ipv6/current/ mail74.html to get an idea of what I'm thinking of. Iljitsch _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram <39C363776A4E8C4A94691D2BD9D1C9A1017747C8@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F49223B-1D88-4A1C-967C-F87DD56C7FBA@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on Date: Mon, 19 Mar 2007 17:22:55 +0100 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=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: 1ac7cc0a4cd376402b85bc1961a86ac2 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 19-mrt-2007, at 16:46, Templin, Fred L wrote: >> I guess I have a draft to write. :-) > And the problem with *my* draft is... ?? That (from a quick scan) it doesn't actually make it possible to have systems with different MTUs on the same subnet? Have a look at the discussion under "Re: jumbo frame of GbE and IPv6 -- A proposal" on http://www1.ietf.org/mail-archive/web/ipv6/current/ mail74.html to get an idea of what I'm thinking of. Iljitsch _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 12:43: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 1HTKvg-0000RV-Ud; Mon, 19 Mar 2007 12:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKvf-0000RJ-J6 for ram@iab.org; Mon, 19 Mar 2007 12:41:51 -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 1HTKvd-0008C9-9W for ram@iab.org; Mon, 19 Mar 2007 12:41:51 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2JGfPIU015126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Mar 2007 11:41:25 -0500 (CDT) 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 l2JGfPUx019485; Mon, 19 Mar 2007 11:41:25 -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 l2JGfFFO019039; Mon, 19 Mar 2007 11:41:24 -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, 19 Mar 2007 09:41:21 -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] what we should be working on Date: Mon, 19 Mar 2007 09:41:20 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747CB@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4F49223B-1D88-4A1C-967C-F87DD56C7FBA@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] what we should be working on Thread-Index: AcdqQtvYwzepXl9HRsqjkOBoJa12aQAAMqMg References: <45F94921.7010707@piuha.net><45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747C8@XCH-NW-7V2.nw.nos.boeing.com> <4F49223B-1D88-4A1C-967C-F87DD56C7FBA@muada.com> From: "Templin, Fred L" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 19 Mar 2007 16:41:21.0648 (UTC) FILETIME=[6CF2AF00:01C76A45] 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 > That (from a quick scan) it doesn't actually make it possible=20 > to have =20 > systems with different MTUs on the same subnet? Huh? I don't see any problem at all. The tunnel is configured over an underlying link and can discover an MTU up to the MTU that is configured on the underlying link, and that can be independent and different from the MTUs configured by any other hosts connected to the same underlying link. Or, maybe I don't understand what you mean by "subnet"? =20 > Have a look at the discussion under "Re: jumbo frame of GbE and IPv6 =20 > -- A proposal" on http://www1.ietf.org/mail-archive/web/ipv6/current/=20 > mail74.html to get an idea of what I'm thinking of. This discussion has been going on for a long time, hasn't it? :^} Maybe sit down with the draft and let's compare notes. IMHO, the mechanism is all there, but could benefit from some fine-tuning. But, I don't see the limitation you are referring to. Thanks - Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 13:12: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 1HTLMq-0001i9-IM; Mon, 19 Mar 2007 13:09:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLMo-0001hz-T9 for ram@iab.org; Mon, 19 Mar 2007 13:09:54 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTLMm-0006FR-C1 for ram@iab.org; Mon, 19 Mar 2007 13:09:54 -0400 Received: from [IPv6:2001:df8::16:20a:95ff:fef5:246e] ([IPv6:2001:df8:0:16:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2JH9LlN001423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2007 18:09:22 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747CB@XCH-NW-7V2.nw.nos.boeing.com> References: <45F94921.7010707@piuha.net><45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747C8@XCH-NW-7V2.nw.nos.boeing.com> <4F49223B-1D88-4A1C-967C-F87DD56C7FBA@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747CB@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on Date: Mon, 19 Mar 2007 18:09:43 +0100 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=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: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 19-mrt-2007, at 17:41, Templin, Fred L wrote: >> That (from a quick scan) it doesn't actually make it possible >> to have systems with different MTUs on the same subnet? > Huh? I don't see any problem at all. The tunnel is configured > over an underlying link and can discover an MTU up to the MTU > that is configured on the underlying link, and that can be > independent and different from the MTUs configured by any other > hosts connected to the same underlying link. Or, maybe I don't > understand what you mean by "subnet"? For simplicity, let's assume this to be a logical ethernet segment. (I mean, who uses anything other that ethernet nowadays anyways?) Suppose: host A (8192) host C (9216) \ / switch 1 (2048) --- switch 2 (9000) / \ host B (9000) host D (16384) The IEEE solution here is extremely simple: use 1500 bytes. The operational solution is to look at the diagram and either: 1. set up a 2048 byte MTU on all hosts manually 2. determine that going from 1500 to 2048 isn't worth the trouble and do nothing 3. replace switch 1 and configure a 8192 byte MTU manually on all hosts This is just too hard, especially if most traffic is towards other destinations so you're probably limited to a 1500 byte path MTU anyway. But if we can automate all of this on the IP level, hosts and routers will automatically adopt the lowest common MTU, so over time, more and more places will be able to hande 1500+ packets without headaches for operators. >> Have a look at the discussion under "Re: jumbo frame of GbE and IPv6 >> -- A proposal" on http://www1.ietf.org/mail-archive/web/ipv6/ >> current/ >> mail74.html to get an idea of what I'm thinking of. > This discussion has been going on for a long time, hasn't > it? :^} I don't think it has been going all this time... Didn't follow through back then. > Maybe sit down with the draft and let's compare > notes. IMHO, the mechanism is all there, but could benefit > from some fine-tuning. But, I don't see the limitation you > are referring to. Sure, let me know when, I'll read your draft in more detail beforehand. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 13:12: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 1HTLOU-0002Bp-ML; Mon, 19 Mar 2007 13:11:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLOT-0002Bh-JG for ram@iab.org; Mon, 19 Mar 2007 13:11:37 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTLOR-0006VO-7z for ram@iab.org; Mon, 19 Mar 2007 13:11:37 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1B45D86AF1; Mon, 19 Mar 2007 13:11:28 -0400 (EDT) To: iab@ietf.org, ram@iab.org Subject: Re: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Message-Id: <20070319171128.1B45D86AF1@mercury.lcs.mit.edu> Date: Mon, 19 Mar 2007 13:11:28 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: jnc@mercury.lcs.mit.edu 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: Leslie Daigle > the purpose of this document is strictly and uniquely to document the > discussion that occurred at the workshop. > ... > Comments that help clarify the text as a representation of what was > discussed at the event will be gratefully accepted for the document. > Every else -- is input to the current discussions That's a logical position to take, but if so, the workshop report needs to carry a clear disclaimer, up front, that some of the conclusions drawn in it are now known to be incorrect. That will alert the unwary not to put undue reliance on any statements therein. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 13:12: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 1HTLMq-0001i9-IM; Mon, 19 Mar 2007 13:09:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLMo-0001hz-T9 for ram@iab.org; Mon, 19 Mar 2007 13:09:54 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTLMm-0006FR-C1 for ram@iab.org; Mon, 19 Mar 2007 13:09:54 -0400 Received: from [IPv6:2001:df8::16:20a:95ff:fef5:246e] ([IPv6:2001:df8:0:16:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2JH9LlN001423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2007 18:09:22 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747CB@XCH-NW-7V2.nw.nos.boeing.com> References: <45F94921.7010707@piuha.net><45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747C8@XCH-NW-7V2.nw.nos.boeing.com> <4F49223B-1D88-4A1C-967C-F87DD56C7FBA@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747CB@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on Date: Mon, 19 Mar 2007 18:09:43 +0100 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=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: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 19-mrt-2007, at 17:41, Templin, Fred L wrote: >> That (from a quick scan) it doesn't actually make it possible >> to have systems with different MTUs on the same subnet? > Huh? I don't see any problem at all. The tunnel is configured > over an underlying link and can discover an MTU up to the MTU > that is configured on the underlying link, and that can be > independent and different from the MTUs configured by any other > hosts connected to the same underlying link. Or, maybe I don't > understand what you mean by "subnet"? For simplicity, let's assume this to be a logical ethernet segment. (I mean, who uses anything other that ethernet nowadays anyways?) Suppose: host A (8192) host C (9216) \ / switch 1 (2048) --- switch 2 (9000) / \ host B (9000) host D (16384) The IEEE solution here is extremely simple: use 1500 bytes. The operational solution is to look at the diagram and either: 1. set up a 2048 byte MTU on all hosts manually 2. determine that going from 1500 to 2048 isn't worth the trouble and do nothing 3. replace switch 1 and configure a 8192 byte MTU manually on all hosts This is just too hard, especially if most traffic is towards other destinations so you're probably limited to a 1500 byte path MTU anyway. But if we can automate all of this on the IP level, hosts and routers will automatically adopt the lowest common MTU, so over time, more and more places will be able to hande 1500+ packets without headaches for operators. >> Have a look at the discussion under "Re: jumbo frame of GbE and IPv6 >> -- A proposal" on http://www1.ietf.org/mail-archive/web/ipv6/ >> current/ >> mail74.html to get an idea of what I'm thinking of. > This discussion has been going on for a long time, hasn't > it? :^} I don't think it has been going all this time... Didn't follow through back then. > Maybe sit down with the draft and let's compare > notes. IMHO, the mechanism is all there, but could benefit > from some fine-tuning. But, I don't see the limitation you > are referring to. Sure, let me know when, I'll read your draft in more detail beforehand. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 13:12: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 1HTLOU-0002Bp-ML; Mon, 19 Mar 2007 13:11:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLOT-0002Bh-JG for ram@iab.org; Mon, 19 Mar 2007 13:11:37 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTLOR-0006VO-7z for ram@iab.org; Mon, 19 Mar 2007 13:11:37 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1B45D86AF1; Mon, 19 Mar 2007 13:11:28 -0400 (EDT) To: iab@ietf.org, ram@iab.org Subject: Re: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Message-Id: <20070319171128.1B45D86AF1@mercury.lcs.mit.edu> Date: Mon, 19 Mar 2007 13:11:28 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: jnc@mercury.lcs.mit.edu 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: Leslie Daigle > the purpose of this document is strictly and uniquely to document the > discussion that occurred at the workshop. > ... > Comments that help clarify the text as a representation of what was > discussed at the event will be gratefully accepted for the document. > Every else -- is input to the current discussions That's a logical position to take, but if so, the workshop report needs to carry a clear disclaimer, up front, that some of the conclusions drawn in it are now known to be incorrect. That will alert the unwary not to put undue reliance on any statements therein. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 13:30: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 1HTLes-0004F3-0q; Mon, 19 Mar 2007 13:28:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLer-0004EL-0x for ram@iab.org; Mon, 19 Mar 2007 13:28:33 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTLee-00089o-Jx for ram@iab.org; Mon, 19 Mar 2007 13:28:32 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 17:28:17 +0000 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 17:28:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] application endpoint identifiers in map-and-encaps schemes Date: Mon, 19 Mar 2007 17:28:15 -0000 Message-ID: <70B775CD6175D84B978C843BDDF683970D8B2EB0@i2km96-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: application endpoint identifiers in map-and-encaps schemes Thread-Index: AcdqL1F9G4MtI8q7QDS1jOp5zevu0wAGjuiA References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C2@XCH-NW-7V2.nw.nos.boeing.com> From: To: , , X-OriginalArrivalTime: 19 Mar 2007 17:28:16.0341 (UTC) FILETIME=[FAA2C050:01C76A4B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] Sent: Mon 19/03/2007 14:03 To: rrg; ram@iab.org Subject: [RAM] application endpoint identifiers in map-and-encaps = schemes =20 During the RRG meeting on Saturday, Lixia presented a slide suggesting that not only locators and identifiers are desired, but also a possible separation in the identifer in terms of what the physical interface of the end node sees and what the *application endpoint* within the end node sees.=20 [alb]i see that node, network and interfaces all might have identifiers = and locators. it seems that some people also see separate spaces = depending on role as "edge" or "user". These all could have global or = local scope, be transient or intransient. The trick is to decide the = minimal set that you can get away with. I think a lot of proposals on = loc/id split often have a node id that is used as an application = endpoint,and that is intransient (doesn't need to change to keep the = network running) and a locator that maps to the physical presence on the = net - the interface locator, or an end network that can then recah the = device.=20 I interpret this as follows: - let locators be assigned to the tunnel interfaces of ingress/egress tunnel routers - let *node* identifiers be assigned to the physical interfaces of end systems - let *application* identifiers be assigned to virtual interfaces (e.g., loopback interfaces) within end systems This could allow for the Ethernet-to-WiFi handoff Lixia referred to in her slide with no need to readdress the application endpoint identifiers, since only the node identifier changes. [alb] careful of terminology as you will ofetn find node id used to mean = application endpoint id in much of the literature The following text from (IPvLX, Section 3) speaks to this: "3. Addressing and Routing Assumptions While IPv4 addresses in the current Internet are typically assigned to devices, IPvLX assumes that IPv6 addresses will also be assigned to application endpoints and data objects [NAME]. This new model would provide greater flexibility such that each end-node might host many different IPv6 application endpoints and data objects, and that those entities could migrate to other end-nodes. In this model, each IPv6 addressable entity would access other endpoints via an IPv6 router." [alb] I think an IP address actually is assigned to the interface to a = node.An ethernet address can be considered the ID of that interface. at = a local level that ID can be used to discover a path. Fred fred.l.templin@boeing.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 Mar 19 13:42: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 1HTLqi-0004OH-AI; Mon, 19 Mar 2007 13:40:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLqh-0004JZ-2h for ram@iab.org; Mon, 19 Mar 2007 13:40:47 -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 1HTLqb-0007ld-1w for ram@iab.org; Mon, 19 Mar 2007 13:40:47 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2JHecJw028951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Mar 2007 12:40:38 -0500 (CDT) 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 l2JHec3w003465; Mon, 19 Mar 2007 12:40:38 -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 l2JHeLrD002698; Mon, 19 Mar 2007 12:40:34 -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, 19 Mar 2007 10:40: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] application endpoint identifiers in map-and-encaps schemes Date: Mon, 19 Mar 2007 10:40:33 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747CE@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <70B775CD6175D84B978C843BDDF683970D8B2EB0@i2km96-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] application endpoint identifiers in map-and-encaps schemes Thread-Index: AcdqL1F9G4MtI8q7QDS1jOp5zevu0wAGjuiAAACqdCA= References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C2@XCH-NW-7V2.nw.nos.boeing.com> <70B775CD6175D84B978C843BDDF683970D8B2EB0@i2km96-ukbr.domain1.systemhost.net> From: "Templin, Fred L" To: , , X-OriginalArrivalTime: 19 Mar 2007 17:40:34.0053 (UTC) FILETIME=[B258AB50:01C76A4D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 Louise, Thanks for this, and you are certainly correct that an address is ultimately assigned to an *interface*; not an application, or a node, or etc. That point doesn't come across well in the text, but I think I see a way clear to fix it and your feedback has helped. Fred fred.l.templin@boeing.com > -----Original Message----- > From: louise.burness@bt.com [mailto:louise.burness@bt.com]=20 > Sent: Monday, March 19, 2007 10:28 AM > To: Templin, Fred L; rrg@psg.com; ram@iab.org > Subject: RE: [RAM] application endpoint identifiers in=20 > map-and-encaps schemes >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Mon 19/03/2007 14:03 > To: rrg; ram@iab.org > Subject: [RAM] application endpoint identifiers in=20 > map-and-encaps schemes > =20 > During the RRG meeting on Saturday, Lixia presented a slide > suggesting that not only locators and identifiers are desired, > but also a possible separation in the identifer in terms of > what the physical interface of the end node sees and what the > *application endpoint* within the end node sees.=20 >=20 > [alb]i see that node, network and interfaces all might have=20 > identifiers and locators. it seems that some people also see=20 > separate spaces depending on role as "edge" or "user". These=20 > all could have global or local scope, be transient or=20 > intransient. The trick is to decide the minimal set that you=20 > can get away with. I think a lot of proposals on loc/id split=20 > often have a node id that is used as an application=20 > endpoint,and that is intransient (doesn't need to change to=20 > keep the network running) and a locator that maps to the=20 > physical presence on the net - the interface locator, or an=20 > end network that can then recah the device.=20 >=20 > I interpret > this as follows: >=20 > - let locators be assigned to the tunnel interfaces of > ingress/egress tunnel routers > - let *node* identifiers be assigned to the physical > interfaces of end systems > - let *application* identifiers be assigned to virtual > interfaces (e.g., loopback interfaces) within end > systems >=20 > This could allow for the Ethernet-to-WiFi handoff Lixia referred > to in her slide with no need to readdress the application endpoint > identifiers, since only the node identifier changes. >=20 > [alb] careful of terminology as you will ofetn find node id=20 > used to mean application endpoint id in much of the literature >=20 > The following text from (IPvLX, Section 3) speaks to this: >=20 > "3. Addressing and Routing Assumptions >=20 > While IPv4 addresses in the current Internet are typically assigned > to devices, IPvLX assumes that IPv6 addresses will also be assigned > to application endpoints and data objects [NAME]. This new model > would provide greater flexibility such that each end-node=20 > might host > many different IPv6 application endpoints and data=20 > objects, and that > those entities could migrate to other end-nodes. In this=20 > model, each > IPv6 addressable entity would access other endpoints via an IPv6 > router." >=20 > [alb] I think an IP address actually is assigned to the=20 > interface to a node.An ethernet address can be considered the=20 > ID of that interface. at a local level that ID can be used to=20 > discover a path. >=20 > Fred > fred.l.templin@boeing.com >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 13:43: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 1HTLsz-0006DR-Ib; Mon, 19 Mar 2007 13:43:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLsy-0006DK-Vc for ram@iab.org; Mon, 19 Mar 2007 13:43:09 -0400 Received: from imo-m27.mx.aol.com ([64.12.137.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTLsb-0003HJ-Gl for ram@iab.org; Mon, 19 Mar 2007 13:43:08 -0400 Received: from HeinerHummel@aol.com by imo-m27.mx.aol.com (mail_out_v38_r7.6.) id z.ce0.d14a66e (52349); Mon, 19 Mar 2007 13:42:14 -0400 (EDT) Received: from FWM-M10 (fwm-m10.webmail.aol.com [64.12.168.74]) by ciaaol-r01.mx.aol.com (v114_r3.4) with ESMTP id MAILCIAAOLR017-cc7d45fecb7620f; Mon, 19 Mar 2007 13:42:14 -0400 References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> To: iljitsch@muada.com, jari.arkko@piuha.net Subject: Re: [RAM] what we should be working on Date: Mon, 19 Mar 2007 13:42:14 -0400 In-Reply-To: <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> X-MB-Message-Source: WebUI Received: from 62.84.152.90 by FWM-M10.sysops.aol.com (64.12.168.74) with HTTP (WebMailUI); Mon, 19 Mar 2007 13:42:14 -0400 MIME-Version: 1.0 From: heinerhummel@aol.com X-MB-Message-Type: User X-Mailer: AOL eMail 24126 Message-Id: <8C9386510C30DCC-1780-504F@FWM-M10.sysops.aol.com> X-AOL-IP: 64.12.168.74 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b 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="===============1714027037==" Errors-To: ram-bounces@iab.org --===============1714027037== Content-Type: multipart/alternative; boundary="--------MB_8C9386510C0AB73_1780_8E6F_FWM-M10.sysops.aol.com" ----------MB_8C9386510C0AB73_1780_8E6F_FWM-M10.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Doubling the size of the IP packet is certainly not a help with respect to V= OIP or video transmission. Heiner =20 =20 -----Urspr=C3=BCngliche Mitteilung-----=20 Von: iljitsch@muada.com An: jari.arkko@piuha.net Cc: ram@iab.org Verschickt: Mo., 19. Mrz. 2007, 8:12 Thema: Re: [RAM] what we should be working on On 17-mrt-2007, at 17:02, Jari Arkko wrote:=20 =20 >> What I'm thinking of here is increasing the average size of IP=20 >> packets, because the bad stuff, such as the number of FIB lookups=20 >> required, typically scales at O(#packets) while the good stuff=20 >> typically scales at O(bandwidth).=20 =20 > I am all for increasing the average size of packets. But I'll note > that=20 > its probably not a panacea. Router cost, for instance, is a function=20 > of many factors, including FIB looks, filtering, fancy prioritizing=20 > schemes as well as line speed. And Path MTU increase is one of those=20 > nasty things where the weakest link counts, so getting that deployed=20 > requires updates in several places. But yes, I think it would still=20 > be useful.=20 =20 Yes, there are many reasons why this is and has been a low-return investment= . However, we're rapidly approaching the situation where, for a significant=20= number of paths, at every hop, the hardware supports packet sizes larger tha= n 1500 bytes, but we have no reasonable way of using this capability where i= t exists. But if we can make things such that the largest packets possible a= re used, over time, more and more packets will be larger than 1500 bytes so=20= the growth in the total amount of per-packet work will start to trail the gr= owth in bandwidth. Over time, the savings in processing power / energy use w= ill become more and more significant.=20 =20 I guess I have a draft to write. :-)=20 =20 _______________________________________________=20 RAM mailing list=20 RAM@iab.org=20 https://www1.ietf.org/mailman/listinfo/ram=20 ________________________________________________________________________ Kostenlos: AOL eMail 2 GB Speicherplatz sowie erstklassiger Spam- und eMail Virenschutz. Sichern Sie sich Ihre pers=C3=B6nliche eMail Adresse noch heute! ----------MB_8C9386510C0AB73_1780_8E6F_FWM-M10.sysops.aol.com Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Do= ubling the size of the IP packet is certainly not a help with respect to VOI= P or video transmission.
Heiner
 
 
-----Urspr=C3=BCngliche Mitteilung-----
Von: iljitsch@muada.com
An: jari.arkko@piuha.net
Cc: ram@iab.org
Verschickt: Mo., 19. Mrz. 2007, 8:12
Thema: Re: [RAM] what we should be working on

On 17-mrt-2007, at 17:02, Jari Arkko wrote: 
 
>> What I'm thinking of here is increasing the average size of IP = ;
>> packets, because the bad stuff, such as the number of FIB lookups&n= bsp;
>> required, typically scales at O(#packets) while the good stuff = ;
>> typically scales at O(bandwidth). 
 
> I am all for increasing the average size of packets. But I'll note >= that 
> its probably not a panacea. Router cost, for instance, is a function&nb= sp;
> of many factors, including FIB looks, filtering, fancy prioritizing&nbs= p;
> schemes as well as line speed. And Path MTU increase is one of those&nb= sp;
> nasty things where the weakest link counts, so getting that deployed&nb= sp;
> requires updates in several places. But yes, I think it would still&nbs= p;
> be useful. 
 
Yes, there are many reasons why this is and has been a low-return investment= . However, we're rapidly approaching the situation where, for a significant=20= number of paths, at every hop, the hardware supports packet sizes larger tha= n 1500 bytes, but we have no reasonable way of using this capability where i= t exists. But if we can make things such that the largest packets possible a= re used, over time, more and more packets will be larger than 1500 bytes so=20= the growth in the total amount of per-packet work will start to trail the gr= owth in bandwidth. Over time, the savings in processing power / energy use w= ill become more and more significant. 
 
I guess I have a draft to write. :-) 
 
_______________________________________________ 
RAM mailing list 
RAM@iab.org 
https= ://www1.ietf.org/mailman/listinfo/ram 
Kostenlos: AOL eMa= il
2 GB Speicherplatz sowie erstklassiger Spam- und eMail Virenschutz.
Sichern Sie sich Ihre pers=C3=B6nliche eMail Adresse noch heute!
----------MB_8C9386510C0AB73_1780_8E6F_FWM-M10.sysops.aol.com-- --===============1714027037== 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 --===============1714027037==-- From ram-bounces@iab.org Mon Mar 19 13:50: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 1HTM0G-0001nD-GN; Mon, 19 Mar 2007 13:50:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTM0E-0001n2-O9 for ram@iab.org; Mon, 19 Mar 2007 13:50:38 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTM06-00013R-Cq for ram@iab.org; Mon, 19 Mar 2007 13:50:38 -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 6330985; Mon, 19 Mar 2007 12:50:30 -0500 In-Reply-To: <8C9386510C30DCC-1780-504F@FWM-M10.sysops.aol.com> References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <8C9386510C30DCC-1780-504F@FWM-M10.sysops.aol.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marshall Eubanks Subject: Re: [RAM] what we should be working on Date: Mon, 19 Mar 2007 13:50:24 -0400 To: heinerhummel@aol.com X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Mar 19, 2007, at 1:42 PM, heinerhummel@aol.com wrote: > Doubling the size of the IP packet is certainly not a help with =20 > respect to VOIP or video transmission. > Heiner > This is a MAY not a MUST, so it wouldn't hurt. But at any case, while =20= VOIP would generally not gain much from larger packet MTU sizes, video certainly would, at least for the =20= higher bandwidths. At 1 Mbps and 30 fps, for example, video would certainly benefit from jumbo frames. Regards Marshall > > -----Urspr=FCngliche Mitteilung----- > Von: iljitsch@muada.com > An: jari.arkko@piuha.net > Cc: ram@iab.org > Verschickt: Mo., 19. Mrz. 2007, 8:12 > Thema: Re: [RAM] what we should be working on > > On 17-mrt-2007, at 17:02, Jari Arkko wrote: > > >> What I'm thinking of here is increasing the average size of IP > >> packets, because the bad stuff, such as the number of FIB lookups > >> required, typically scales at O(#packets) while the good stuff > >> typically scales at O(bandwidth). > > > I am all for increasing the average size of packets. But I'll =20 > note > that > > its probably not a panacea. Router cost, for instance, is a function > > of many factors, including FIB looks, filtering, fancy prioritizing > > schemes as well as line speed. And Path MTU increase is one of those > > nasty things where the weakest link counts, so getting that deployed > > requires updates in several places. But yes, I think it would still > > be useful. > > Yes, there are many reasons why this is and has been a low-return =20 > investment. However, we're rapidly approaching the situation where, =20= > for a significant number of paths, at every hop, the hardware =20 > supports packet sizes larger than 1500 bytes, but we have no =20 > reasonable way of using this capability where it exists. But if we =20 > can make things such that the largest packets possible are used, =20 > over time, more and more packets will be larger than 1500 bytes so =20 > the growth in the total amount of per-packet work will start to =20 > trail the growth in bandwidth. Over time, the savings in processing =20= > power / energy use will become more and more significant. > > I guess I have a draft to write. :-) > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > Kostenlos: AOL eMail > 2 GB Speicherplatz sowie erstklassiger Spam- und eMail Virenschutz. > Sichern Sie sich Ihre pers=F6nliche eMail Adresse noch heute! > _______________________________________________ > 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 Mar 19 13:57:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTM5k-0002oC-VN; Mon, 19 Mar 2007 13:56:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTM5j-0002o7-Ka for ram@iab.org; Mon, 19 Mar 2007 13:56:19 -0400 Received: from jazz.viagenie.ca ([206.123.31.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTM5g-0006j4-8q for ram@iab.org; Mon, 19 Mar 2007 13:56:19 -0400 Received: from [130.129.17.221] (dhcp-11dd.ietf68.org [130.129.17.221]) by jazz.viagenie.ca (Postfix) with ESMTP id A5D5129E1326 for ; Mon, 19 Mar 2007 13:56:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: Marc Blanchet Subject: Re: full IPv6 transition, was: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Mon, 19 Mar 2007 18:56:12 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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, 19 Mar 2007 15:50:51 +0000, Tim Chown wrote: > I met Marc Blancet this morning. He has IPv6 PI, and is now having fun > seeing where his /48 is seen :) s/Blancet/Blanchet/. having fun "on purpose": - from all ARIN PI assigned, there were a few weeks ago only two prefixes that were advertised on the v6 internet. One is from a company that is not doing it for production (I contacted the guy to have more info on his experience and he told me that was his weekend playground project). The other PI advertised on the v6 internet is ours (2620:0:230::/48). Obviously, that might change any day. - we are running v6 in production. Since a month now, I've been contacting providers that were filtering our prefix and ALL were very responsive to fix their filter to let PI routes being advertised. So things improving every day. So it looks like we are punching holes so that other PI will be ok. After some time, I'm thinking of reporting the work and status to some operational community (nanog or ...). Marc. ----- IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 14:22: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 1HTMTb-0002dx-Vg; Mon, 19 Mar 2007 14:20:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMO6-00008j-Rd for ram@iab.org; Mon, 19 Mar 2007 14:15:18 -0400 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTMDx-0002wG-In for ram@iab.org; Mon, 19 Mar 2007 14:04:54 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 53790342DD; Mon, 19 Mar 2007 14:04:46 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 14:03:57 -0400 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] Architectural comments on draft-farinacci-lisp-00 Date: Mon, 19 Mar 2007 14:03:55 -0400 Message-ID: <816DD9299957E547B5D758D7F977D6DC01A03BA6@tayexc14.americas.cpqcorp.net> In-Reply-To: <45FEB8EC.8000408@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Architectural comments on draft-farinacci-lisp-00 Thread-Index: AcdqQuUXDWxl9OgxSjK2c1rQYys9dgADf8Ww References: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> <816DD9299957E547B5D758D7F977D6DC0179E968@tayexc14.americas.cpqcorp.net> <816DD9299957E547B5D758D7F977D6DC019B2A6C@tayexc14.americas.cpqcorp.net> <45FE6DF4.20303@piuha.net> <816DD9299957E547B5D758D7F977D6DC01A03A2F@tayexc14.americas.cpqcorp.net> <45FEB8EC.8000408@piuha.net> From: "Bound, Jim" To: "Jari Arkko" X-OriginalArrivalTime: 19 Mar 2007 18:03:57.0175 (UTC) FILETIME=[F6AC1870:01C76A50] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Pekka Nikander , 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 thank you Jari appreciate you staying on top of this list with all your other jobs in the IETF. /jim=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Monday, March 19, 2007 12:23 PM > To: Bound, Jim > Cc: Pekka Nikander; ram@iab.org > Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 >=20 > Dave Ward will be talking about requirements from a routing=20 > system / deployment point of view, and I believe this is=20 > largely going to be based on Dino's material. And this in=20 > turn, was the rationale behind LISP. >=20 > I am very much in agreement with you that we need a deployable scheme. >=20 > Jari >=20 >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 14:43:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMmw-0000tF-0R; Mon, 19 Mar 2007 14:40:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMmu-0000t2-FD for ram@iab.org; Mon, 19 Mar 2007 14:40:56 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTMms-0005WQ-1J for ram@iab.org; Mon, 19 Mar 2007 14:40:56 -0400 Received: from [10.10.64.154] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 19 Mar 2007 11:40:35 -0700 X-Server-Uuid: 20144BB6-FB76-4F11-80B6-E6B2900CA0D7 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id E428D2B2; Mon, 19 Mar 2007 11:40:34 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id AF1682B1; Mon, 19 Mar 2007 11:40:34 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBV92463; Mon, 19 Mar 2007 11:40:33 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 8573520501; Mon, 19 Mar 2007 11:40:33 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RAM] what we should be working on Date: Mon, 19 Mar 2007 11:40:31 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A410342878E@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <2CE4F14A-A065-4911-A888-E00FD33B457D@muada.com> Thread-Topic: [RAM] what we should be working on Thread-Index: AcdqPvEpxtr/8wmPQtazBlyScgqkDgAFOdOg From: "Puneet Agarwal" To: "Iljitsch van Beijnum" X-WSS-ID: 69E006A938G5663079-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Iljitsch, Software lookup based routers are definitely helped with lower packets/sec. However, most (all?) of the core routers deployed implement hardware based lookups (for the required lookup rates on even a reasonably density 1G solution). Moreover, the benchmarks for these devices are not based on average packet rates but based on peak packet rates (ie for 64 bytes). Larger MTU helps the average pkt rate but not the peak pkt rate. Hence larger MTU (while helpful under some constrained scenarios) would not really help the stringent lookup bandwidth requirements for core/edge routers with large FIBs. Thanks. -Puneet -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 Sent: Monday, March 19, 2007 8:55 AM To: Puneet Agarwal Cc: Jari Arkko; ram@iab.org Subject: Re: [RAM] what we should be working on On 19-mrt-2007, at 16:23, Puneet Agarwal wrote: > Lookup bandwidth is dominated by small packets (all the TCP acks that=20 > are flowing). Increasing the MTU to be > 1500 will not solve the=20 > lookup bandwidth problem. Almost 50% of all packets are 64 bytes (on > Ethernet) > and a little smaller over PPP. > Hence increased MTU (greater than 1500) will not solve the lookup bw=20 > problem. Not sure what you mean by "solve". General purpose computers almost always use less power when idle than when doing work. If this is true for routers doing FIB lookups (not a given, but I don't see how it would be possible to authoritatively say it can NEVER be true in the future) then having fewer packets for a given amount of bandwidth is helpful. Obviously there are applications that generate small packets, so a larger MTU won't make those packets larger. But for TCP it does help. =20 If you have to send 100 packets with 1500 byte packets but only 20 with large packets, this means that the number of TCP ACKs will go down from approximately 50 to approximately 10 and the total from 150 to 30. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 15:28: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 1HTNUG-0000iS-Hy; Mon, 19 Mar 2007 15:25:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTNUF-0000iL-Oq for ram@iab.org; Mon, 19 Mar 2007 15:25:43 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTNU5-0000Jr-63 for ram@iab.org; Mon, 19 Mar 2007 15:25:43 -0400 Received: from [192.168.1.182] (tulip-inn-terminus.fwa.tiscali.cz [195.146.103.206]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2JJOWli004095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2007 20:24:33 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747C2@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C2@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <91390EE4-E9E6-4F08-96CA-40DEAE5FE5A6@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] application endpoint identifiers in map-and-encaps schemes Date: Mon, 19 Mar 2007 20:24:48 +0100 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 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: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ram@iab.org, rrg 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 19-mrt-2007, at 15:03, Templin, Fred L wrote: > During the RRG meeting on Saturday, Lixia presented a slide > suggesting that not only locators and identifiers are desired, > but also a possible separation in the identifer in terms of > what the physical interface of the end node sees and what the > *application endpoint* within the end node sees. I interpret > this as follows: > - let locators be assigned to the tunnel interfaces of > ingress/egress tunnel routers > - let *node* identifiers be assigned to the physical > interfaces of end systems > - let *application* identifiers be assigned to virtual > interfaces (e.g., loopback interfaces) within end > systems > This could allow for the Ethernet-to-WiFi handoff Lixia referred > to in her slide with no need to readdress the application endpoint > identifiers, since only the node identifier changes. Hm, applications have their own ideas on identification. For instance, the HTTP protocol carries a hostname in-band. This has several nice properties, including the one that you can run several HTTP servers on a single IP address / port number combination. Another is that the application identifier is exchanged once per session rather than once per packet. It's important to limit what's in packets to what actually needs to be there. And that's basically only demultiplexing information. From that, session state can be recovered, which can include several identifiers per layer of the stack if desired. And is it just me or does it look like we're slowly but surely trying to reinvent CLNP? There your address (oh wait: NSAP) isn't tied to a single interface but rather to the host in general. This does of course mean that even local communication requires a router and you need a host-to-router routing protocol. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 16:04: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 1HTO2i-0004sI-P8; Mon, 19 Mar 2007 16:01:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTO2h-0004r5-6u for ram@iab.org; Mon, 19 Mar 2007 16:01:19 -0400 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTO2I-0007ZQ-NS for ram@iab.org; Mon, 19 Mar 2007 16:01:19 -0400 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id C43C053F3E6; Mon, 19 Mar 2007 15:00:45 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id MNMgiwPMQtyC; Mon, 19 Mar 2007 15:00:33 -0500 (EST) Received: from [192.168.1.59] (unknown [65.199.96.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id E953653E0EA; Mon, 19 Mar 2007 15:00:30 -0500 (EST) In-Reply-To: <20070319034300.GA21041@vaf-lnx1.cisco.com> References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> <20070319034300.GA21041@vaf-lnx1.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: "John G. Scudder" Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Mon, 19 Mar 2007 16:00:23 -0400 To: Vince Fuller X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: iab@ietf.org, 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 Mar 18, 2007, at 11:43 PM, Vince Fuller wrote: > 2) The majority of more-specific prefixes in the global routing > system are > advertised intentionally for traffic engineering or other > purposes. In > other words, relatively few more-specifics are configuration > errors that > would go away if only network operators were better educated. > One ipv6 > prefix would be needed for each of the observed IPv4 more- > specifics that > are intentionally advertised today. This is 74K prefixes. Since some of the entities advertising more-specifics have likely obtained multiple blocks of address space, from which the more- specifics are taken, then it would seem to follow that in the IPv6 case where we assume that each entity really just needs a single address block, they'll advertise fewer more specifics. That is to say, there may be more than one more-specific per site now, because of the history of how address blocks were allocated, but in the IPv6 world one would hope for only a single more-specific per site. So 74k seems like an overcount, though I imagine not grossly so. (I.e., I wouldn't dispute it as a rough estimate, which I guess is all it purports to be.) --John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 16:59:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTOw4-0000Uz-Ku; Mon, 19 Mar 2007 16:58:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTOw3-0000Ut-CF for ram@iab.org; Mon, 19 Mar 2007 16:58:31 -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 1HTOvz-0007Ef-W1 for ram@iab.org; Mon, 19 Mar 2007 16:58:31 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2JKwJ6g014348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Mar 2007 13:58:19 -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 l2JKwIhN023048; Mon, 19 Mar 2007 13:58:18 -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 l2JKwEBp022911; Mon, 19 Mar 2007 13:58:18 -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); Mon, 19 Mar 2007 13:58:09 -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] what we should be working on Date: Mon, 19 Mar 2007 13:58:09 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747D4@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <8954613CA6BB3242A1531D916A527A410342878E@NT-SJCA-0751.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] what we should be working on Thread-Index: AcdqPvEpxtr/8wmPQtazBlyScgqkDgAFOdOgAAUiNrA= References: <2CE4F14A-A065-4911-A888-E00FD33B457D@muada.com> <8954613CA6BB3242A1531D916A527A410342878E@NT-SJCA-0751.brcm.ad.broadcom.com> From: "Templin, Fred L" To: "Puneet Agarwal" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 19 Mar 2007 20:58:09.0584 (UTC) FILETIME=[4CCB2300:01C76A69] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Puneet, The reasons that larger packets make sense for Packetization Layer Path MTU Discovery (draft-ietf-pmtud-method) are the same reasons that larger packets make sense for path MTU assurance over tunnels, i.e., the question of whether large packets make sense or not is not specific to tunnels. But, tunnels also have the added responsibility of presenting an assured minimum MTU to upper layers without causing unnecessary fragmentation in the network. Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Puneet Agarwal [mailto:pagarwal@broadcom.com]=20 > Sent: Monday, March 19, 2007 11:41 AM > To: Iljitsch van Beijnum > Cc: ram@iab.org > Subject: RE: [RAM] what we should be working on >=20 > Hi Iljitsch, >=20 > Software lookup based routers are definitely helped with lower > packets/sec. However, most (all?) of the core routers=20 > deployed implement > hardware based lookups (for the required lookup rates on even a > reasonably density 1G solution). Moreover, the benchmarks for these > devices are not based on average packet rates but based on peak packet > rates (ie for 64 bytes). Larger MTU helps the average pkt rate but not > the peak pkt rate. >=20 > Hence larger MTU (while helpful under some constrained=20 > scenarios) would > not really help the stringent lookup bandwidth requirements for > core/edge routers with large FIBs. >=20 > Thanks. >=20 > -Puneet >=20 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > Sent: Monday, March 19, 2007 8:55 AM > To: Puneet Agarwal > Cc: Jari Arkko; ram@iab.org > Subject: Re: [RAM] what we should be working on >=20 > On 19-mrt-2007, at 16:23, Puneet Agarwal wrote: >=20 > > Lookup bandwidth is dominated by small packets (all the TCP=20 > acks that=20 > > are flowing). Increasing the MTU to be > 1500 will not solve the=20 > > lookup bandwidth problem. Almost 50% of all packets are 64 bytes (on > > Ethernet) > > and a little smaller over PPP. >=20 > > Hence increased MTU (greater than 1500) will not solve the=20 > lookup bw=20 > > problem. >=20 > Not sure what you mean by "solve". General purpose computers almost > always use less power when idle than when doing work. If this is true > for routers doing FIB lookups (not a given, but I don't see=20 > how it would > be possible to authoritatively say it can NEVER be true in the > future) then having fewer packets for a given amount of bandwidth is > helpful. >=20 > Obviously there are applications that generate small packets, so a > larger MTU won't make those packets larger. But for TCP it=20 > does help. =20 > If you have to send 100 packets with 1500 byte packets but=20 > only 20 with > large packets, this means that the number of TCP ACKs will go=20 > down from > approximately 50 to approximately 10 and the total from 150 to 30. >=20 >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 17:06: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 1HTP1e-00014t-L8; Mon, 19 Mar 2007 17:04:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTP1c-00014g-RO for ram@iab.org; Mon, 19 Mar 2007 17:04:16 -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 1HTP1b-0007zs-Iz for ram@iab.org; Mon, 19 Mar 2007 17:04:16 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2JL4ECg018117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Mar 2007 14:04:14 -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 l2JL4EPJ016678; Mon, 19 Mar 2007 16:04:14 -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 l2JL43aZ016362; Mon, 19 Mar 2007 16:04:13 -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, 19 Mar 2007 14:04:13 -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] application endpoint identifiers in map-and-encaps schemes Date: Mon, 19 Mar 2007 14:04:12 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747D5@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <91390EE4-E9E6-4F08-96CA-40DEAE5FE5A6@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] application endpoint identifiers in map-and-encaps schemes Thread-Index: AcdqXFS66xUNW2+GQCGs+j4sSjrvaAADQw2A References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C2@XCH-NW-7V2.nw.nos.boeing.com> <91390EE4-E9E6-4F08-96CA-40DEAE5FE5A6@muada.com> From: "Templin, Fred L" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 19 Mar 2007 21:04:13.0260 (UTC) FILETIME=[258FB0C0:01C76A6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ram@iab.org, rrg 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,=20 =20 > And is it just me or does it look like we're slowly but=20 > surely trying =20 > to reinvent CLNP? There your address (oh wait: NSAP) isn't tied to a =20 > single interface but rather to the host in general. Umm - no. I specifically want that addresses be assigned to *interfaces* (not nodes, file systems, data bases, etc) as I said in my message to Louise. The text will be fixed. Fred fred.l.templin@boeing.com=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 18:53:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTQhV-0000Tw-Dj; Mon, 19 Mar 2007 18:51:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTQhT-0000Se-Kv; Mon, 19 Mar 2007 18:51:35 -0400 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTQhE-0000L4-PX; Mon, 19 Mar 2007 18:51:34 -0400 Received: from vaioz1.apnic.net (dhcp13.potaroo.net [203.10.60.13]) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l2JMpFji036723; Tue, 20 Mar 2007 09:51:15 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070320095014.055cbc08@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 20 Mar 2007 09:52:10 +1100 To: Ross Callon , Yakov Rekhter , Lixia Zhang From: Geoff Huston Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt In-Reply-To: <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> References: <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: iab@ietf.org, 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 >Perhaps we should add an additional sentence to either the >abstract or to the last paragraph of section 1 that says: > > Work on issues related to this workshop report is continuing, > and this document does not intend to accurately reflect the > increased understanding of issues nor to discuss the range of > potential solutions that may be the outcome of this ongoing work. Adding additonal paragraphs about what a document is not tends to be a never-ending task! Personally I thought that the document was already adequately clear about its scope as a workshop report. Geoff _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 20:26: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 1HTS7m-0001jA-Rn; Mon, 19 Mar 2007 20:22:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTS7l-0001iz-O8 for ram@iab.org; Mon, 19 Mar 2007 20:22:49 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTS7k-0008Vs-Eq for ram@iab.org; Mon, 19 Mar 2007 20:22:49 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 19 Mar 2007 17:22:45 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l2K0Mh7x008831; Mon, 19 Mar 2007 17:22:43 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2K0Mfwn001938; Tue, 20 Mar 2007 00:22:41 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 17:22:41 -0700 Received: from [130.129.17.126] ([10.21.152.248]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 17:22:39 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] dns discover in map-and-encaps schemes Date: Mon, 19 Mar 2007 17:22:38 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 00:22:40.0994 (UTC) FILETIME=[DF1FB420:01C76A85] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1261; t=1174350163; x=1175214163; 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]=20dns=20discover=20in=20map-and-encaps=20scheme s |Sender:=20; bh=/PASE2N5m+K6H2+mcq4rzazltRCZszgdfRpE6mRJ5ag=; b=PrA6jrlaTpEoJwJWtjBUm1VdaeWFe/ykPD7EIbjoUoUZPAiLksyCNRkCIl2usQPpQAPWExqP mTufX/q60kHW4MgnLl5SW5gJVP8vj11Jc2THawNXaTak+T4b/4aTCVkA; 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: ram@iab.org, rrg 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 > 1) source does DNS lookup for the FQDN "dest.example.com". > 2) source's DNS server is co-resident on the ingress tunnel router > and performs a lookup in the global DNS for a well-known prefix > appended to the FQDN suffix, e.g.: "egress.example.com". > 3) source's DNS server gets back locators for the egress tunnel > router from the global DNS, then sends an IP-in-IP encapsulated > RFC4620 Node Information Query asking the egress tunnel router > to resolve the FQDN "dest.example.com". > 4) egress tunnel router returns identifers associated with > "dest.example.com"; ingress tunnel router caches the resolution > and returns the resolution to the source as response to the > "real" DNS query. What happens when I type "ping " on the source? What if DNS is down, do I lose global connectivity? What if one of the two domain names don't exist in DNS? What if network administrators are totally against making routers DNS servers? What if your ITR is a low- end router where it can store both the DNS cache and mapping database? What I am trying to say is, some things need to go into the network and some things should just stay out of the network. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 20:30: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 1HTSEP-0004y4-Cq; Mon, 19 Mar 2007 20:29:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTSEN-0004xr-RN for ram@iab.org; Mon, 19 Mar 2007 20:29:39 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTSEI-00010D-VP for ram@iab.org; Mon, 19 Mar 2007 20:29:39 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 19 Mar 2007 17:29:34 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2K0TYQr007873; Mon, 19 Mar 2007 17:29: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 l2K0TGZt029409; Tue, 20 Mar 2007 00:29:34 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 17:29:28 -0700 Received: from [130.129.17.126] ([10.21.152.248]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 17:29:28 -0700 In-Reply-To: <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65EE910D-F86F-4671-93DC-EDAC5B24A189@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RRG] Re: [RAM] dns discover in map-and-encaps schemes Date: Mon, 19 Mar 2007 17:29:20 -0700 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 00:29:28.0447 (UTC) FILETIME=[D1FC18F0:01C76A86] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=457; t=1174350574; x=1175214574; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RRG]=20Re=3A=20[RAM]=20dns=20discover=20in=20map-and -encaps=20schemes |Sender:=20; bh=vTHsAy8bXvIFOf/sFQFgXCOEXL6KqR9ZxWQbJ38/iTU=; b=Fj1f+6/1kleo4Vu41lx9wUms62KwSva/DKUUeUtIGaMrq912eCBX12wEkxIVgEvQm2azQoTZ t3i1uE32Y7jNWG07UUTH9nWeU4FOa5BedexAyEG9ZkDkFYVmBwlabvC6; 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: 7bac9cb154eb5790ae3b2913587a40de Cc: "Templin, Fred L" , ram@iab.org, rrg 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 > What happens when I type "ping " on the source? > What if DNS is down, do I lose global connectivity? What if one of > the two domain names don't exist in DNS? What if network > administrators are totally against making routers DNS servers? What > if your ITR is a low-end router where it can store both the DNS > cache and mapping database? Typo, ... if your ITR is a low-end router where it cannot store ...". Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 20:54: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 1HTSab-0001QA-GF; Mon, 19 Mar 2007 20:52:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTSaa-0001NV-0Q for ram@iab.org; Mon, 19 Mar 2007 20:52:36 -0400 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTSaL-0004XW-2E for ram@iab.org; Mon, 19 Mar 2007 20:52:35 -0400 Received: from [10.10.64.154] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Mon, 19 Mar 2007 17:52:08 -0700 X-Server-Uuid: 6B5CFB92-F616-4477-B110-55F967A57302 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 0CA0A2B0; Mon, 19 Mar 2007 17:52:08 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id EBB9C2AE; Mon, 19 Mar 2007 17:52:07 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FBW89204; Mon, 19 Mar 2007 17:52:07 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 0F57A20502; Mon, 19 Mar 2007 17:52:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RAM] what we should be working on Date: Mon, 19 Mar 2007 17:51:51 -0700 Message-ID: <8954613CA6BB3242A1531D916A527A4103428843@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747D4@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: [RAM] what we should be working on Thread-Index: AcdqPvEpxtr/8wmPQtazBlyScgqkDgAFOdOgAAUiNrAACA1rQA== From: "Puneet Agarwal" To: "Templin, Fred L" , "Iljitsch van Beijnum" X-WSS-ID: 69E1EFB23705749612-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 Fred, I have no issue with your argument that to support overlay models (ip tunnels, mpls etc), you want the MTU to be a little larger (say extra 200 bytes) than end node MTU. Fragmentation in the network never did anyone any good. I was merely objecting to the implication that were being drawn that larger mtu will somehow reduce the lookup bandwidth requirements for core/edge routers (which it doesn't). The good news is that service providers have almost always insisted that their network equipment support at least FDDI/T3 MTUs of ~4500 bytes on all links. Hence I do not think that supporting 1500+200=3D1700 byte MTU should be much of a challenge for the SPs (though I do not want to speak for the SPs). Thanks. -Puneet=20 -----Original Message----- From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 Sent: Monday, March 19, 2007 1:58 PM To: Puneet Agarwal; Iljitsch van Beijnum Cc: ram@iab.org Subject: RE: [RAM] what we should be working on Puneet, The reasons that larger packets make sense for Packetization Layer Path MTU Discovery (draft-ietf-pmtud-method) are the same reasons that larger packets make sense for path MTU assurance over tunnels, i.e., the question of whether large packets make sense or not is not specific to tunnels. But, tunnels also have the added responsibility of presenting an assured minimum MTU to upper layers without causing unnecessary fragmentation in the network. Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Puneet Agarwal [mailto:pagarwal@broadcom.com] > Sent: Monday, March 19, 2007 11:41 AM > To: Iljitsch van Beijnum > Cc: ram@iab.org > Subject: RE: [RAM] what we should be working on >=20 > Hi Iljitsch, >=20 > Software lookup based routers are definitely helped with lower=20 > packets/sec. However, most (all?) of the core routers deployed=20 > implement hardware based lookups (for the required lookup rates on=20 > even a reasonably density 1G solution). Moreover, the benchmarks for=20 > these devices are not based on average packet rates but based on peak=20 > packet rates (ie for 64 bytes). Larger MTU helps the average pkt rate=20 > but not the peak pkt rate. >=20 > Hence larger MTU (while helpful under some constrained > scenarios) would > not really help the stringent lookup bandwidth requirements for=20 > core/edge routers with large FIBs. >=20 > Thanks. >=20 > -Puneet >=20 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Monday, March 19, 2007 8:55 AM > To: Puneet Agarwal > Cc: Jari Arkko; ram@iab.org > Subject: Re: [RAM] what we should be working on >=20 > On 19-mrt-2007, at 16:23, Puneet Agarwal wrote: >=20 > > Lookup bandwidth is dominated by small packets (all the TCP > acks that > > are flowing). Increasing the MTU to be > 1500 will not solve the=20 > > lookup bandwidth problem. Almost 50% of all packets are 64 bytes (on > > Ethernet) > > and a little smaller over PPP. >=20 > > Hence increased MTU (greater than 1500) will not solve the > lookup bw > > problem. >=20 > Not sure what you mean by "solve". General purpose computers almost=20 > always use less power when idle than when doing work. If this is true=20 > for routers doing FIB lookups (not a given, but I don't see how it=20 > would be possible to authoritatively say it can NEVER be true in the > future) then having fewer packets for a given amount of bandwidth is=20 > helpful. >=20 > Obviously there are applications that generate small packets, so a=20 > larger MTU won't make those packets larger. But for TCP it does help. > If you have to send 100 packets with 1500 byte packets but only 20=20 > with large packets, this means that the number of TCP ACKs will go=20 > down from approximately 50 to approximately 10 and the total from 150=20 > to 30. >=20 >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 19 21:14: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 1HTSul-00063j-JW; Mon, 19 Mar 2007 21:13:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTSuk-00063D-EH for ram@iab.org; Mon, 19 Mar 2007 21:13:26 -0400 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTSuZ-0007tI-Gn for ram@iab.org; Mon, 19 Mar 2007 21:13:26 -0400 Received: from vaioz1.apnic.net (dhcp13.potaroo.net [203.10.60.13]) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l2K1D5eO037523; Tue, 20 Mar 2007 12:13:06 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070320115246.0143f400@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 20 Mar 2007 12:14:00 +1100 To: Iljitsch van Beijnum , "Templin, Fred L" From: Geoff Huston Subject: Re: [RAM] application endpoint identifiers in map-and-encaps schemes In-Reply-To: <91390EE4-E9E6-4F08-96CA-40DEAE5FE5A6@muada.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C2@XCH-NW-7V2.nw.nos.boeing.com> <91390EE4-E9E6-4F08-96CA-40DEAE5FE5A6@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: rrg , 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 06:24 AM 20/03/2007, Iljitsch van Beijnum wrote: >On 19-mrt-2007, at 15:03, Templin, Fred L wrote: > >>During the RRG meeting on Saturday, Lixia presented a slide >>suggesting that not only locators and identifiers are desired, >>but also a possible separation in the identifer in terms of >>what the physical interface of the end node sees and what the >>*application endpoint* within the end node sees. I interpret >>this as follows: > >Hm, applications have their own ideas on identification. When you start to consider "identifiers" in a general sense there is the appreciation that we have managed to devise "identities" almost everywhere: multi-party applications, application agents, rendezvous protocols, DNS indirection and referral, mobility protocols, SHIM6, SCTP, HIP, TCP, etc There is no single 'identity" - there are a plethora of such identities today groupd within a large set of 'realms' of identity, and I believe that they are an enduring aspect of this environment. This does not lead me to a "we are heading to a CNLP-liker destination" conclusion, as there is no single useful encompassing identifier here, nor do I see any use of value in trying to construct such a beast! As far as I can see there are, and will be, many forms of identity and are, and will be, many ways to map between various identity realms at various levels in the protocol stack. regards, Geoff _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 01: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 1HTXGv-0004tb-1K; Tue, 20 Mar 2007 01:52:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTXGu-0004t8-H7 for ram@iab.org; Tue, 20 Mar 2007 01:52:36 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTXGt-0004l6-79 for ram@iab.org; Tue, 20 Mar 2007 01:52:36 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2007 06:52:34 +0100 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 l2K5qYAU017994; Tue, 20 Mar 2007 06:52:34 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2K5qOlZ017367; Tue, 20 Mar 2007 05:52:30 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 06:52:23 +0100 Received: from [10.0.1.235] ([10.61.64.132]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 06:52:23 +0100 In-Reply-To: References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <8C9386510C30DCC-1780-504F@FWM-M10.sysops.aol.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] what we should be working on Date: Tue, 20 Mar 2007 06:52:23 +0100 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 05:52:23.0856 (UTC) FILETIME=[EEA0E300:01C76AB3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=750; t=1174369954; x=1175233954; c=relaxed/simple; s=amsdkim2001; 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]=20what=20we=20should=20be=20working=20on |Sender:=20; bh=uerGJ7j7oAd/1mYcGNrukw8JiYLUte8S8eRtfvtlh04=; b=enxhmqXsN8DQbhe1Etwv7XhXlvZ1IP0W5wCWwOTJziz3UND+6oXDSxbcWWCMCtHjSHmq4j6F nPaijpmP+FQx2RNh/kbQJXCebsGSkBL8bo1ZW/Ssf9P/6DkzqGR1Rd1d; Authentication-Results: ams-dkim-2; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Mar 19, 2007, at 6:50 PM, Marshall Eubanks wrote: > On Mar 19, 2007, at 1:42 PM, heinerhummel@aol.com wrote: > >> Doubling the size of the IP packet is certainly not a help with >> respect to VOIP or video transmission. >> Heiner >> > > This is a MAY not a MUST, so it wouldn't hurt. But at any case, > while VOIP would generally not gain much > from larger packet MTU sizes, video certainly would, at least for > the higher bandwidths. At 1 Mbps and > 30 fps, for example, video would certainly benefit from jumbo frames. Raising the average packet size would increase jitter. This may well be irrelevant at GigE speeds, but at lower speeds could become significant. Someone should work the figures... Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 03:29: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 1HTYkM-0008PP-6x; Tue, 20 Mar 2007 03:27:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTYkL-0008PJ-1q for ram@iab.org; Tue, 20 Mar 2007 03:27:05 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTYkG-0006rE-6a for ram@iab.org; Tue, 20 Mar 2007 03:27:04 -0400 Received: from [192.168.1.182] (tulip-inn-terminus.fwa.tiscali.cz [195.146.103.206]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2K7QSNp015293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Mar 2007 08:26:29 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <8C9386510C30DCC-1780-504F@FWM-M10.sysops.aol.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <43298230-F92B-426C-8735-84FA78202CF6@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on Date: Tue, 20 Mar 2007 08:26:45 +0100 To: Tony Li X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 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: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 20-mrt-2007, at 6:52, Tony Li wrote: > Raising the average packet size would increase jitter. This may > well be irrelevant at GigE speeds, but at lower speeds could become > significant. Someone should work the figures... How much jitter is acceptable? It would also be helpful to know the amount of buffering that happens in routers and switches, but that seems to be all over the map. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 03:32:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTYop-0000qk-OC; Tue, 20 Mar 2007 03:31:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTYoo-0000qc-GP for ram@iab.org; Tue, 20 Mar 2007 03:31:42 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTYon-0007NQ-6n for ram@iab.org; Tue, 20 Mar 2007 03:31:42 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2007 08:31:37 +0100 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 l2K7Va45001597; Tue, 20 Mar 2007 08:31:36 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2K7VVlZ003836; Tue, 20 Mar 2007 07:31:35 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); Tue, 20 Mar 2007 08:31:31 +0100 Received: from [10.0.1.235] ([10.61.80.125]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 08:31:31 +0100 In-Reply-To: <43298230-F92B-426C-8735-84FA78202CF6@muada.com> References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <8C9386510C30DCC-1780-504F@FWM-M10.sysops.aol.com> <43298230-F92B-426C-8735-84FA78202CF6@muada.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7CF3DDEA-74DF-4117-BD00-7BDF48A21E6D@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] what we should be working on Date: Tue, 20 Mar 2007 08:31:30 +0100 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 07:31:31.0117 (UTC) FILETIME=[C778E5D0:01C76AC1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=730; t=1174375896; x=1175239896; c=relaxed/simple; s=amsdkim2001; 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]=20what=20we=20should=20be=20working=20on |Sender:=20; bh=A+nvu+966lgIoaVjgW8xquEuY8KBTCmzH0J24kjsrp0=; b=DgF9n2wzBIgeCHpEoSspgtQsI4yi9U1aaigolW82gyb/IysYikrecA2g88QK/HRFM+XZTL/b HRWhAhc60Wqlij0ycgyf16ouKTEcvOPcfKSl5y+CGtBbsHOENhxR+z1v; Authentication-Results: ams-dkim-2; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Mar 20, 2007, at 8:26 AM, Iljitsch van Beijnum wrote: > On 20-mrt-2007, at 6:52, Tony Li wrote: > >> Raising the average packet size would increase jitter. This may >> well be irrelevant at GigE speeds, but at lower speeds could >> become significant. Someone should work the figures... > > How much jitter is acceptable? This is also all over the map and is really the domain of our VOIP and video brethren. I'll let them speak for themselves. > > It would also be helpful to know the amount of buffering that > happens in routers and switches, but that seems to be all over the > map. Correct. It very much depends on make and model. There is no hard and fast standard. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 03:40: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 1HTYxK-0007PI-A5; Tue, 20 Mar 2007 03:40:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTYxI-0007P6-2e for ram@iab.org; Tue, 20 Mar 2007 03:40:28 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTYxF-0008Bp-O3 for ram@iab.org; Tue, 20 Mar 2007 03:40:28 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2007 08:40:25 +0100 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 l2K7eOoQ003890; Tue, 20 Mar 2007 08:40:24 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2K7d8ln005947; Tue, 20 Mar 2007 07:40:16 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 08:39:51 +0100 Received: from [10.0.1.235] ([10.61.80.125]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 08:39:51 +0100 In-Reply-To: References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> <20070319034300.GA21041@vaf-lnx1.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] Re: Impending publication: draft-iab-raws-report-01.txt Date: Tue, 20 Mar 2007 08:39:51 +0100 To: "John G. Scudder" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 07:39:51.0523 (UTC) FILETIME=[F1BCCB30:01C76AC2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1192; t=1174376424; x=1175240424; c=relaxed/simple; s=amsdkim2001; 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]=20Re=3A=20Impending=20publication=3A=20draft-ia b-raws-report-01.txt |Sender:=20; bh=Egzg3vdOBxzLhQT5ZZIpzKCX6LHP/KYPiktSO7RnHpo=; b=LApn79NRQ7zi6bGSD9nNtJE+9/8S8cjGcsOcIhtazxtObc/lkEt0KGBmlCzMx6a7XQUqY2GA RBFQyLu0/d9njFuDS9Oo/l93eS30W3f4dsMAjwZ/KxXQ25Apq8zGR+v1; Authentication-Results: ams-dkim-2; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: iab@ietf.org, 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 Mar 19, 2007, at 9:00 PM, John G. Scudder wrote: > Since some of the entities advertising more-specifics have likely > obtained multiple blocks of address space, from which the more- > specifics are taken, then it would seem to follow that in the IPv6 > case where we assume that each entity really just needs a single > address block, they'll advertise fewer more specifics. That is to > say, there may be more than one more-specific per site now, because > of the history of how address blocks were allocated, but in the > IPv6 world one would hope for only a single more-specific per site. I find myself a bit skeptical of this. I would imagine that there are v4 sites that are generating more than one specific from a single aggregate for TE purposes. I would expect that behavior to continue in v6. Perhaps the multiplier for multiple prefixes will go away, but I see no reason to believe that the underlying techniques for TE will change. How big of a problem this is, I can't say. I don't know if anyone has done any kind of analysis of the average number of more specifics if someone does decide to de-aggregate. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 04:54: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 1HTa4C-0004qj-34; Tue, 20 Mar 2007 04:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTa4B-0004qe-3N for ram@iab.org; Tue, 20 Mar 2007 04:51:39 -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 1HTa47-0006wb-LW for ram@iab.org; Tue, 20 Mar 2007 04:51:39 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2K8pWC3003013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Mar 2007 01:51:32 -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 l2K8pWaZ005901; Tue, 20 Mar 2007 01:51:32 -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 l2K8pVNT005876; Tue, 20 Mar 2007 01:51:32 -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, 20 Mar 2007 01:51:31 -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] dns discover in map-and-encaps schemes Date: Tue, 20 Mar 2007 01:51:30 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] dns discover in map-and-encaps schemes Thread-Index: AcdqheFAkn3UdcuJTamc9VS4fYUX0wAQ3KYg References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> From: "Templin, Fred L" To: "Dino Farinacci" X-OriginalArrivalTime: 20 Mar 2007 08:51:31.0593 (UTC) FILETIME=[F4C76790:01C76ACC] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ram@iab.org, rrg 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 Dino,=20 > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com]=20 > Sent: Monday, March 19, 2007 5:23 PM > To: Templin, Fred L > Cc: rrg; ram@iab.org > Subject: Re: [RAM] dns discover in map-and-encaps schemes >=20 > > 1) source does DNS lookup for the FQDN "dest.example.com". > > 2) source's DNS server is co-resident on the ingress tunnel router > > and performs a lookup in the global DNS for a well-known prefix > > appended to the FQDN suffix, e.g.: "egress.example.com". > > 3) source's DNS server gets back locators for the egress tunnel > > router from the global DNS, then sends an IP-in-IP encapsulated > > RFC4620 Node Information Query asking the egress tunnel router > > to resolve the FQDN "dest.example.com". > > 4) egress tunnel router returns identifers associated with > > "dest.example.com"; ingress tunnel router caches the resolution > > and returns the resolution to the source as response to the > > "real" DNS query. >=20 > What happens when I type "ping " on the source? Not quite certain what you mean; do you mean ping the source IP address from the destination IP address after the source has done the DNS mapping for the destination. The intent is the egress tunnel router nearest the destination will have cached the source IP to locator mapping and so the ping will succeed. > What if DNS is down, do I lose global connectivity? What happens if the DNS is down in today's Internet? You can ping any global IPv4 address and connect to any global IPv4 services by specifying an IP address instead of a FQDN, and the very same will be true for this scheme. The only thing you *won't* be able to do is ping IPv6 addresses and connect to IPv6 services that are deeply embedded in distant sites, but that is the very same condition as for devices that are deeply embedded behind NATs in todays Internet. Bottom line is the situation for loss of global DNS is no different from and no worse than for the existing condition of today's Internet. > What if one of the two domain names don't exist in DNS? The idea is that the global DNS will only ever contain FQDNs for IPv4-based services; not for any IPv6-based services. So, there will be only one FQDN in the DNS ("egress.example.com"), and the FQDN "peer.example.com" will be in the site-specific name service for the peer's site. The "egress.example.com" gives the ingress tunnel router unambiguous indication that the egress tunnel router is participating in the scheme, so the absense of this FQDN is a clear indication that the peer's site does *not* implement the scheme. This only means that the egress tunnel router is responsible for ensuring that its FQDN is well-maintained in the global DNS.=20 > What if network administrators are totally against making routers DNS > servers? I want that the function be moved closer to the end devices, and not in core routers - but, see more below: > What if your ITR is a low-end router where it can (not) store both the > DNS cache and mapping database? The router doesn't need to store the full DNS cache, because the function it is performing is not exactly that of a full DNS server. It is really a "two-faced" DNS server that can resolve the FQDNs for end nodes that are within the same site, but acts as a DNS resolver for FQDNs for end nodes that reside within different sites. So, it does not keep a database of global FQDN-to-resource record mappings - it resolves them from another DNS server just the same as an ordinary DNS resolver would do. =20 > What I am trying to say is, some things need to go into the network =20 > and some things should just stay out of the network. I'm all for pushing the function closer to the end devices, and preferrably on the end devices themselves. That would be consistent with RFC1955. Thanks - Fred fred.l.templin@boeing.com =20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 05:02: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 1HTaEF-0001mP-5j; Tue, 20 Mar 2007 05:02:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTaED-0001mH-Mc for ram@iab.org; Tue, 20 Mar 2007 05:02:01 -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 1HTaEC-000877-El for ram@iab.org; Tue, 20 Mar 2007 05:02:01 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2K91hQW024775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Mar 2007 04:01:44 -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 l2K91hrK014992; Tue, 20 Mar 2007 02:01:43 -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 l2K91gGw014989; Tue, 20 Mar 2007 02:01:43 -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, 20 Mar 2007 02:01:42 -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] what we should be working on Date: Tue, 20 Mar 2007 02:01:41 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747D7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <8954613CA6BB3242A1531D916A527A4103428843@NT-SJCA-0751.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] what we should be working on Thread-Index: AcdqPvEpxtr/8wmPQtazBlyScgqkDgAFOdOgAAUiNrAACA1rQAARIu2w References: <39C363776A4E8C4A94691D2BD9D1C9A1017747D4@XCH-NW-7V2.nw.nos.boeing.com> <8954613CA6BB3242A1531D916A527A4103428843@NT-SJCA-0751.brcm.ad.broadcom.com> From: "Templin, Fred L" To: "Puneet Agarwal" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 20 Mar 2007 09:01:42.0788 (UTC) FILETIME=[61145C40:01C76ACE] X-Spam-Score: 0.0 (/) 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 Puneet, =20 > I have no issue with your argument that to support overlay models (ip > tunnels, mpls etc), you want the MTU to be a little larger (say extra > 200 bytes) than end node MTU. No; I didn't say that at all. I want that the tunnel not fragment but also that it can scale its MTU up to larger sizes as appropriate to the path MTU from within the tunnel; 1500 bytes-plus-change is too limiting. > Fragmentation in the network never did anyone any good. Right, and one of the main goals of the proposal is to avoid in-the-network fragmentation. =20 > I was merely objecting to the implication that were being drawn that > larger mtu will somehow reduce the lookup bandwidth requirements for > core/edge routers (which it doesn't). I didn't mean to imply that (I believe you may have been the one who first asserted this?), because I think that is only one facet of the more complex question as to whether larger packet sizes in the Internet are desireable. And again, this is a question for the larger issue of raising the MTU in the Internet; it is not specific to tunnel MTU assurance. > The good news is that service providers have almost always=20 > insisted that > their network equipment support at least FDDI/T3 MTUs of=20 > ~4500 bytes on > all links. Hence I do not think that supporting 1500+200=3D1700 byte = MTU > should be much of a challenge for the SPs (though I do not=20 > want to speak > for the SPs). Already spoke to the 1500-plus-change assertion above; that's too limiting and it is setting the bar too low for what we want to accomplish. Fred fred.l.templin@boeing.com=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 05:58:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTb1U-00046l-BZ; Tue, 20 Mar 2007 05:52:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTb1T-000460-FO for ram@iab.org; Tue, 20 Mar 2007 05:52:55 -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 1HTb1S-0000y3-5M for ram@iab.org; Tue, 20 Mar 2007 05:52:55 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2K9qo61003006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Mar 2007 02:52:51 -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 l2K9qofI004652; Tue, 20 Mar 2007 02:52:50 -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 l2K9qnKA004610; Tue, 20 Mar 2007 02:52:50 -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, 20 Mar 2007 02:52: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 Date: Tue, 20 Mar 2007 02:52:48 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747DB@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Initial comments on the LISP proposal Thread-Index: AcdqheFAkn3UdcuJTamc9VS4fYUX0wAQ3KYgAAIgauA= References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com><031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: , "rrg" X-OriginalArrivalTime: 20 Mar 2007 09:52:49.0452 (UTC) FILETIME=[84F426C0:01C76AD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [RAM] Initial comments on the LISP proposal 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 Dino/Vince/Dave, Some initial comments on the LISP proposal: 1) The ICMP reply that is triggered by the first packet(s) from the ITR to the ETR do not seem to contain any information that could help the ITR know that the reply is in fact coming from a legitimate on-path ETR. Perhaps add a message digest (MD5 or other) to the ICMP reply so that off-path attacker risks can be mitigated? 2) The mechanism is really an open-ended automatic tunneling mechanism. This means that it will send encapsulated packets without having any way of knowing whether a suitably-configured decapsulator exists on the path. Some systems may refuse to accept encapsulated packets if they do not have at least a tunnel interface configured a priori, and some systems may not configure a tunnel interface by default. I *think* we found this to be the case on Linux FC5 (system wouldn't accept the packets w/o a tunnel interface configured) but I need to go back and verify. 3) Sending encapsulated packets when there is no way of knowing whether there is a suitably-configured decapsulator on the path could fail to reach some services, e.g., services that reside behind NAT boxes and have "holes" punched in the NAT that only recognize unencapsulated packets. 4) The spec doesn't say for how long the ITR will continue to send encapsulated packets when it gets no replies back from an ETR. Will it continue to send the encapsulated packets for the entire duration of the flow? If so, this may not work in some cases (see above) and will add unnecessary encapsulation overhead in other cases. Either way, it seems that legacy systems may suffer before the scheme becomes widely deployed. 5) There is also the issue of unnessary IP fragmentation on the path when the ITR is not careful about the size of the tunneled packets it sends. 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 Mar 20 06:06: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 1HTbBT-0000pK-7a; Tue, 20 Mar 2007 06:03:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbBS-0000pE-IC for ram@iab.org; Tue, 20 Mar 2007 06:03:14 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTbBR-0003T4-4V for ram@iab.org; Tue, 20 Mar 2007 06:03:14 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id EDCA81138B7; Tue, 20 Mar 2007 11:03:03 +0100 (CET) Received: from [163.117.203.92] (unknown [163.117.203.92]) by smtp02.uc3m.es (Postfix) with ESMTP id 86C77113901; Tue, 20 Mar 2007 11:03:03 +0100 (CET) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747DB@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com><031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747DB@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Date: Tue, 20 Mar 2007 11:05:13 +0100 To: "Templin, Fred L" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ram@iab.org, rrg Subject: [RAM] Re: [RRG] Initial comments on the LISP proposal 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 El 20/03/2007, a las 10:52, Templin, Fred L escribi=F3: > Dino/Vince/Dave, > > Some initial comments on the LISP proposal: > > 1) The ICMP reply that is triggered by the first packet(s) from the > ITR to the ETR do not seem to contain any information that could > help the ITR know that the reply is in fact coming from a > legitimate on-path ETR. Perhaps add a message digest (MD5 or other) > to the ICMP reply so that off-path attacker risks can be mitigated? > maybe you want to check http://www.rfc-editor.org/cgi-bin/iddoctype.pl?letsgo=3Ddraft-bagnulo-=20= lisp-threat-00 regards, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 06:19: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 1HTbPz-0004Bc-ID; Tue, 20 Mar 2007 06:18:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbPy-0004BO-Lv for ram@iab.org; Tue, 20 Mar 2007 06:18:14 -0400 Received: from omzesmtp03.mci.com ([199.249.17.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTbPu-0008BY-0L for ram@iab.org; Tue, 20 Mar 2007 06:18:14 -0400 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JF700CJO5XE87@firewall.mci.com> for ram@iab.org; Tue, 20 Mar 2007 10:17:38 +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 <0JF700I595XEOY@dgismtp06.mcilink.com> for ram@iab.org; Tue, 20 Mar 2007 10:17:38 +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 <0JF700I565XDHG@dgismtp06.mcilink.com> for ram@iab.org; Tue, 20 Mar 2007 10:17:38 +0000 (GMT) Date: Tue, 20 Mar 2007 10:17:37 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] what we should be working on In-reply-to: <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Iljitsch van Beijnum Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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, 19 Mar 2007, Iljitsch van Beijnum wrote: > >> What I'm thinking of here is increasing the average size of IP > >> packets, because the bad stuff, such as the number of FIB lookups > >> required, typically scales at O(#packets) while the good stuff > >> typically scales at O(bandwidth). > > Yes, there are many reasons why this is and has been a low-return > investment. However, we're rapidly approaching the situation where, > for a significant number of paths, at every hop, the hardware > supports packet sizes larger than 1500 bytes, but we have no > reasonable way of using this capability where it exists. But if we So... just thinking out loud here, the majority of end-system media is ethernet, that's where the packet size problem exists isn't it? can't the upstream of the majority of these systems (cable or dsl) support >1500 bytes so the real issue is: 1) get ethernet mtu 'fixed' 2) providers will/should increase MTU on tail circuits Does 1000bt (like in many/most 'new' computers 10/100/1000 copper) do jumbo-frames already? So is this a problem? _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 06:27: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 1HTbZ2-0000Il-8F; Tue, 20 Mar 2007 06:27:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbZ0-0000IY-7h for ram@iab.org; Tue, 20 Mar 2007 06:27:34 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTbYw-000314-V3 for ram@iab.org; Tue, 20 Mar 2007 06:27:34 -0400 Received: from pmismtp04.wcomnet.com ([166.37.158.164]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JF700G4O6DTG7@firewall.mci.com> for ram@iab.org; Tue, 20 Mar 2007 10:27:29 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([127.0.0.1]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JF700L3F6DTRY@pmismtp04.mcilink.com> for ram@iab.org; Tue, 20 Mar 2007 10:27:29 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JF700K4K6DSX7@pmismtp04.mcilink.com> for ram@iab.org; Tue, 20 Mar 2007 10:27:29 +0000 (GMT) Date: Tue, 20 Mar 2007 10:27:28 +0000 (GMT) From: "Chris L. Morrow" Subject: RE: [RAM] what we should be working on In-reply-to: <8954613CA6BB3242A1531D916A527A410342870D@NT-SJCA-0751.brcm.ad.broadcom.com> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Puneet Agarwal Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <8954613CA6BB3242A1531D916A527A410342870D@NT-SJCA-0751.brcm.ad.broadcom.com> X-Spam-Score: 0.1 (/) 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 On Mon, 19 Mar 2007, Puneet Agarwal wrote: > Hi Iljitsch, > > Lookup bandwidth is dominated by small packets (all the TCP acks that > are flowing). Increasing the MTU to be > 1500 will not solve the lookup > bandwidth problem. Almost 50% of all packets are 64 bytes (on Ethernet) > and a little smaller over PPP. > > Hence increased MTU (greater than 1500) will not solve the lookup bw > problem. Note that I'm not convinced there IS a problem with MTU size, but could it be that increasing MTU will decrease ack flows? For say a 10k total data xfer today you'd send ~7 full packets if your MTU were 5k you'd send 2, so 5 less acks. What's interesting is that over a short 10min sample of data (admittedly a small sample) packet average size seems to be 489 bytes. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 06:29: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 1HTbaR-0000Z9-9q; Tue, 20 Mar 2007 06:29:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbaQ-0000Z1-8v for ram@iab.org; Tue, 20 Mar 2007 06:29:02 -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 1HTbaL-0003EO-1R for ram@iab.org; Tue, 20 Mar 2007 06:29:02 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 20 Mar 2007 03:28:57 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2KASuew015701; Tue, 20 Mar 2007 03:28:56 -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 l2KASpEi019164; Tue, 20 Mar 2007 10:28:56 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, 20 Mar 2007 03:28:51 -0700 Received: from [130.129.17.126] ([10.21.96.60]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 03:28:50 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.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: Dino Farinacci Subject: Re: [RAM] dns discover in map-and-encaps schemes Date: Tue, 20 Mar 2007 03:28:49 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 10:28:50.0767 (UTC) FILETIME=[8D32A5F0:01C76ADA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1420; t=1174386536; x=1175250536; 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]=20dns=20discover=20in=20map-and-encaps=20scheme s |Sender:=20; bh=zU0r7vvR2W7Bpt5lSkeTN8KgGLFmAjWOJVKOA6qG5Oo=; b=slmPhe+8eDVhaW6rUD+fdpqFBdxzKWSG6wVW62GdmJV9Vg07nEB/rJOj9j8B342KGOKxRbES 6HA5j0+NSkvJaqts6y0z2m8xt03js6hjSwM6rhe7S/w3mo+2ZQwhCCXW; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ram@iab.org, rrg 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 >> What happens when I type "ping " on the source? > > Not quite certain what you mean; do you mean ping the source IP > address from the destination IP address after the source has done > the DNS mapping for the destination. The intent is the egress tunnel > router nearest the destination will have cached the source IP to > locator mapping and so the ping will succeed. No, it was a simple statement about what if a host uses addresses to send packets and not DNS names. >> What if DNS is down, do I lose global connectivity? > > What happens if the DNS is down in today's Internet? You can I can still "[ping,traceroute] ". I can still send packets, I can still type in "http://192.168.0.1/" in my browser. > ping any global IPv4 address and connect to any global IPv4 > services by specifying an IP address instead of a FQDN, and > the very same will be true for this scheme. The only thing How do you get locators when the DNS is down? > you *won't* be able to do is ping IPv6 addresses and connect > to IPv6 services that are deeply embedded in distant sites, A problem. >> What if network administrators are totally against making routers DNS >> servers? > > I want that the function be moved closer to the end devices, and > not in core routers - but, see more below: That still won't make network administrators happier. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 06:32: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 1HTbdM-0002YU-7z; Tue, 20 Mar 2007 06:32:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbdK-0002Np-Na for ram@iab.org; Tue, 20 Mar 2007 06:32:02 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTbdI-0003eh-DZ for ram@iab.org; Tue, 20 Mar 2007 06:32:02 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2007 11:32:00 +0100 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 l2KAVt4Z026327; Tue, 20 Mar 2007 11:31:55 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2KAVnlb002195; Tue, 20 Mar 2007 10:31:49 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 11:31:49 +0100 Received: from [130.129.18.65] ([10.61.66.79]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 11:31:49 +0100 In-Reply-To: References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.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] what we should be working on Date: Tue, 20 Mar 2007 11:31:46 +0100 To: "Chris L. Morrow" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 10:31:49.0063 (UTC) FILETIME=[F7787570:01C76ADA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=421; t=1174386715; x=1175250715; c=relaxed/simple; s=amsdkim2001; 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]=20what=20we=20should=20be=20working=20on |Sender:=20; bh=UYa33SZn1WcKnoA3dRW5HSZ9sAuAHr/CD5ni6PBtYm0=; b=kIhBJhct7HXCbVX7syIZIsyJ9ql986yOEzmU40juRKIT7Xp6Dv0oyplawvnXJgnKfx3WGIMW q7+mAskGGKGR5fuMn6vmjopNyyMLFPHxemyCQPlVG4/zQ3H7UbZptRrH; Authentication-Results: ams-dkim-2; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/amsdkim2001 verified; ); 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 On Mar 20, 2007, at 11:17 AM, Chris L. Morrow wrote: > Does 1000bt (like in many/most 'new' computers 10/100/1000 copper) do > jumbo-frames already? So is this a problem? AFAIK, jumbo frames are *not* standardized and have been repeatedly rejected by the IEEE. The IETF is less than willing to step on the IEEE's turf and so has historically declined to make its own standards in this area. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 06:32: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 1HTbe4-0003zZ-D3; Tue, 20 Mar 2007 06:32:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbe3-0003zO-3H for ram@iab.org; Tue, 20 Mar 2007 06:32:47 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTbdv-0003jh-RX for ram@iab.org; Tue, 20 Mar 2007 06:32:47 -0400 Received: from I2KF03BV-UKBR.domain1.systemhost.net ([193.113.197.43]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 10:32:39 +0000 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by I2KF03BV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Mar 2007 10:32:38 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] what we should be working on Date: Tue, 20 Mar 2007 10:29:55 -0000 Message-ID: <70B775CD6175D84B978C843BDDF683970D8B2EB8@i2km96-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] what we should be working on Thread-Index: Acdq2nyOuMhKYZPqQ+GWM4S3Lxv5kAAADc4C References: <8954613CA6BB3242A1531D916A527A410342870D@NT-SJCA-0751.brcm.ad.broadcom.com> From: To: , X-OriginalArrivalTime: 20 Mar 2007 10:32:38.0294 (UTC) FILETIME=[14D08360:01C76ADB] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 ________________________________ From: Chris L. Morrow [mailto:christopher.morrow@verizonbusiness.com] Sent: Tue 20/03/2007 10:27 To: Puneet Agarwal Cc: ram@iab.org Subject: RE: [RAM] what we should be working on On Mon, 19 Mar 2007, Puneet Agarwal wrote: > Hi Iljitsch, > > Lookup bandwidth is dominated by small packets (all the TCP acks that > are flowing). Increasing the MTU to be > 1500 will not solve the = lookup > bandwidth problem. Almost 50% of all packets are 64 bytes (on = Ethernet) > and a little smaller over PPP. > > Hence increased MTU (greater than 1500) will not solve the lookup bw > problem. Note that I'm not convinced there IS a problem with MTU size, but could = it be that increasing MTU will decrease ack flows? For say a 10k total data xfer today you'd send ~7 full packets if your MTU were 5k you'd send 2, = so 5 less acks. What's interesting is that over a short 10min sample of data (admittedly = a small sample) packet average size seems to be 489 bytes. [alb] from what i remember, you get a lot of very short (100byte ish) = packets (acks, dns queries etc) and a lot of 1500 byte packets (ie if = you plotted number of packets agaisnt packet size, you get 2 peaks, each = containing about half the packets)=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 Mar 20 06:47:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbqB-0003mX-9N; Tue, 20 Mar 2007 06:45:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbqA-0003mP-Az for ram@iab.org; Tue, 20 Mar 2007 06:45:18 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTbq7-0006TW-Vb for ram@iab.org; Tue, 20 Mar 2007 06:45:17 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 20 Mar 2007 03:45:15 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2KAjF1j028646; Tue, 20 Mar 2007 03:45:15 -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 l2KAjDEi026978; Tue, 20 Mar 2007 10:45:13 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, 20 Mar 2007 03:45:13 -0700 Received: from [130.129.17.126] ([10.21.96.60]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 03:45:12 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747DB@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com><031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747DB@XCH-NW-7V2.nw.nos.boeing.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: Dino Farinacci Date: Tue, 20 Mar 2007 03:45:11 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 10:45:12.0798 (UTC) FILETIME=[D688AFE0:01C76ADC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3269; t=1174387515; x=1175251515; 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[RRG]=20Initial=20comments=20on=20the=20LISP=20propos al |Sender:=20; bh=STybeP2dTs9AVt8+n0nzTxy+Olo1fZdO/MCFLntgOes=; b=sD0zrBlAqOocWftmnGrfqrljtYHT9i9943gqGLFAyIHSU36Y7ewE2MnQ9k3y/Ww0y1ew3Fq0 RpkCk4Rifwua+/Vm+19NI9kuHJuLtoo+2W+Sv/MUb4eeTO+V2vu+sfei; 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: d8ae4fd88fcaf47c1a71c804d04f413d Cc: rrg , ram@iab.org Subject: [RAM] Re: [RRG] Initial comments on the LISP proposal 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 > Some initial comments on the LISP proposal: Thanks for the comments. > 1) The ICMP reply that is triggered by the first packet(s) from the > ITR to the ETR do not seem to contain any information that could The Reply goes from the ETR to the ITR. > help the ITR know that the reply is in fact coming from a > legitimate on-path ETR. Perhaps add a message digest (MD5 or other) > to the ICMP reply so that off-path attacker risks can be mitigated? Security is going to be addressed in the -01 draft. By using nonces and not accepting unsolicited replies solves most of this. > 2) The mechanism is really an open-ended automatic tunneling > mechanism. > This means that it will send encapsulated packets without having > any > way of knowing whether a suitably-configured decapsulator exists on This depends on how you do the mapping. If the mapping is pushed and the ETR registers Locators, then you do know. When you don't know, the host sends packet a ICMP protocol unreachable message. For TE tunnels, you do know because most likely shared-keys will be used so there will be a bilateral setup of the tunnel. That means, a technical contract between two ISPs. > the path. Some systems may refuse to accept encapsulated packets if > they do not have at least a tunnel interface configured a priori, This depends on the implementation. I plan to not support it this way. LISP does not require the implementation to configure static tunnel interfaces in the ITRs and ETRs but strongly recommends it for TE-ITRs and TE-ETRs. > 3) Sending encapsulated packets when there is no way of knowing > whether there is a suitably-configured decapsulator on the path > could fail to reach some services, e.g., services that reside > behind NAT boxes and have "holes" punched in the NAT that only > recognize unencapsulated packets. Same issue when you don't inject your site based route into BGP. > 4) The spec doesn't say for how long the ITR will continue to send > encapsulated packets when it gets no replies back from an ETR. I will fix that, but intentionally left it out so I can get some implementation experience first before choosing a number. > Will it continue to send the encapsulated packets for the entire > duration of the flow? If so, this may not work in some cases (see > above) and will add unnecessary encapsulation overhead in other > cases. Either way, it seems that legacy systems may suffer before > the scheme becomes widely deployed. We will be using routable-IDs globally only for the first phase. We plan to have a LISP 3.0 solution soon so we never have routable IDs. That is the best direction to pursue. The ultimate goal should be to address all sites with PI blocks and not have those blocks injected into BGP. We really need to get to this goal as soon as possible (for both IPv4 and IPv6). > 5) There is also the issue of unnessary IP fragmentation on the path > when the ITR is not careful about the size of the tunneled packets > it sends. Yep, a problem with any tunneling design. Thanks again. I will get numbers in the spec in about a month or so. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 06:57: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 1HTbzw-0003nF-GM; Tue, 20 Mar 2007 06:55:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTbzu-0003aW-MS for ram@iab.org; Tue, 20 Mar 2007 06:55:22 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTbzu-0007fo-DG for ram@iab.org; Tue, 20 Mar 2007 06:55:22 -0400 Received: from [IPv6:2001:df8::48:20a:95ff:fecd:987a] ([IPv6:2001:df8:0:48:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2KAslpm019140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Mar 2007 11:54:48 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03EDD675-CD47-4145-AF95-76EE6C7218D1@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on Date: Tue, 20 Mar 2007 11:55:10 +0100 To: Tony Li X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=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: 97adf591118a232206bdb5a27b217034 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 20-mrt-2007, at 11:31, Tony Li wrote: >> Does 1000bt (like in many/most 'new' computers 10/100/1000 copper) do >> jumbo-frames already? So is this a problem? > AFAIK, jumbo frames are *not* standardized and have been repeatedly > rejected by the IEEE. The IETF is less than willing to step on the > IEEE's turf and so has historically declined to make its own > standards in this area. Jumboframe capability of some sort is very common, but certainly not universal in NICs that support gigabit ethernet, with or without 10 and 100 Mbps ethernet capability. There is no common jumboframe size. I've seen stuff in the 1500 - 2048 byte range and 9000, 9216, 16384 and 64000 bytes. Note that jumboframes must invariably be enabled manually. Not being privvy to IEEE internals, I assume the problem the IEEE has with changing the 802.3 maximum packet size is twofold: 1. Existing 802.3 standards mandate 1500 bytes and there is no support for fragmentation so if a newer standard supports larger packets, it won't be possible to internetwork equipment adhering to the old and new standards because the old stuff can't handle the 1500 + packets. (The graybeards among us may at this point fondly think back to bridging between ethernet and FDDI.) 2. 802.3 has a length field where Ethernet II has a type field. The type and length values don't clash for ~1500 bytes but they do for larger packets. Argument 1. disappears when we fix this at the IP layer because unlike ethernet, IP can fragment. Argument 2. is irrelevant for IP because we use Ethernet II and not 802.3 encapsulation. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 07:07: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 1HTcAN-0000EV-1k; Tue, 20 Mar 2007 07:06:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTcAL-0000EN-Kn for ram@iab.org; Tue, 20 Mar 2007 07:06:09 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTcAJ-0000zE-Ad for ram@iab.org; Tue, 20 Mar 2007 07:06:09 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2007 12:06:07 +0100 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 l2KB66MQ016633; Tue, 20 Mar 2007 12:06:06 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2KB62lZ013964; Tue, 20 Mar 2007 11:06:06 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 12:06:02 +0100 Received: from [130.129.18.65] ([10.61.80.190]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 12:06:02 +0100 In-Reply-To: <03EDD675-CD47-4145-AF95-76EE6C7218D1@muada.com> References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <03EDD675-CD47-4145-AF95-76EE6C7218D1@muada.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6B017A22-F89B-4B82-AC86-D6C9F0523168@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] what we should be working on Date: Tue, 20 Mar 2007 12:05:59 +0100 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 11:06:02.0111 (UTC) FILETIME=[BF2EB8F0:01C76ADF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=424; t=1174388766; x=1175252766; 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]=20what=20we=20should=20be=20working=20on |Sender:=20; bh=OhHV/0KLSc/ry5LauKBnbn7FAMpTki7PCAanilGTSsw=; b=auw8CTGDyP6Ci4OHGGGHYBRLn09tW3DOWrOmACufkfuZgENdihb6WK3AVdt1wZrPyP5Tiwha Aj/C7hk2jSJLn86ZFuMSNAtJRJ6xJBfTrV42iH+Cgw/g2os+vgRwp2aN; 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: 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 Mar 20, 2007, at 11:55 AM, Iljitsch van Beijnum wrote: > Argument 1. disappears when we fix this at the IP layer because > unlike ethernet, IP can fragment. I refer you to www.ecse.rpi.edu/Homepages/shivkuma/teaching/sp2001/ readings/ccr-9501-mogulf1.pdf. > Argument 2. is irrelevant for IP because we use Ethernet II and not > 802.3 encapsulation. Except for an annoying IGP called IS-IS. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 07:21: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 1HTcNt-0003sa-U6; Tue, 20 Mar 2007 07:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTcNs-0003sS-N4 for ram@iab.org; Tue, 20 Mar 2007 07:20:08 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTcNn-0003tp-9g for ram@iab.org; Tue, 20 Mar 2007 07:20:08 -0400 Received: from [IPv6:2001:df8::48:20a:95ff:fecd:987a] ([IPv6:2001:df8:0:48:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2KBJc97019728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Mar 2007 12:19:39 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <6B017A22-F89B-4B82-AC86-D6C9F0523168@cisco.com> References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <03EDD675-CD47-4145-AF95-76EE6C7218D1@muada.com> <6B017A22-F89B-4B82-AC86-D6C9F0523168@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5CB3C6C5-4BCF-4B7B-A9D7-283EF7468854@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on Date: Tue, 20 Mar 2007 12:20:00 +0100 To: Tony Li X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.3 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: 9466e0365fc95844abaf7c3f15a05c7d 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 20-mrt-2007, at 12:05, Tony Li wrote: >> Argument 1. disappears when we fix this at the IP layer because >> unlike ethernet, IP can fragment. > I refer you to www.ecse.rpi.edu/Homepages/shivkuma/teaching/sp2001/ > readings/ccr-9501-mogulf1.pdf. "On a high-speed LAN, throughput can increase almost linearly with packet size over a wide range of sizes. Therefore, we prefer to make our packets as large as possible." :-) The point is that IP and its higher layer protocols can adjust the size of the packets sent so IP can adapt to varying MTUs. In some cases this requires fragmentation but in general, TCP or the application protocol on top of UDP makes sure the packets are of an optimum size, which is obviously much better. Ethernet does not have these capabilities. >> Argument 2. is irrelevant for IP because we use Ethernet II and >> not 802.3 encapsulation. > Except for an annoying IGP called IS-IS. Obviously if we can make IP use varying MTUs towards different hosts on the same subnet we should only use jumboframes for IP, not for non- IP protocols. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 08:07: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 1HTd5j-0004nL-Of; Tue, 20 Mar 2007 08:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTd5i-0004ic-Cx for ram@iab.org; Tue, 20 Mar 2007 08:05:26 -0400 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTd5c-0001CB-ED for ram@iab.org; Tue, 20 Mar 2007 08:05:26 -0400 Received: from [10.0.1.39] (dhcp-4009.ietf68.org [130.129.64.9]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id l2KC5Cur015370; Tue, 20 Mar 2007 05:05:12 -0700 (PDT) In-Reply-To: References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> <20070319034300.GA21041@vaf-lnx1.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <18C09EFB-05BE-4170-9D16-8120A22311EB@cs.ucla.edu> Content-Transfer-Encoding: 7bit From: Lixia Zhang Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Tue, 20 Mar 2007 05:05:10 -0700 To: Tony Li X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Mar 20, 2007, at 12:39 AM, Tony Li wrote: > On Mar 19, 2007, at 9:00 PM, John G. Scudder wrote: > >> Since some of the entities advertising more-specifics have likely >> obtained multiple blocks of address space, from which the more- >> specifics are taken, then it would seem to follow that in the IPv6 >> case where we assume that each entity really just needs a single >> address block, they'll advertise fewer more specifics. That is to >> say, there may be more than one more-specific per site now, >> because of the history of how address blocks were allocated, but >> in the IPv6 world one would hope for only a single more-specific >> per site. > > > I find myself a bit skeptical of this. I would imagine that there > are v4 sites that are generating more than one specific from a > single aggregate for TE purposes. I would expect that behavior to > continue in v6. Perhaps the multiplier for multiple prefixes will > go away, but I see no reason to believe that the underlying > techniques for TE will change. Also another big factor that has not been mentioned (or maybe I missed it since I have not read all the msgs:( is the IPv4 address shortage, which has been a very effectively constraint on the DFZ table growth. > How big of a problem this is, I can't say. I don't know if anyone > has done any kind of analysis of the average number of more > specifics if someone does decide to de-aggregate. We did some measurements on de-aggregation a few years ago (see ref's at the end of our RRG presentation slides, available on RRG wiki page). as part of PHAS (prefix hijack alert system) Colorado State has collected data for the current de-aggregation. If people are interested, we can package up the data and upload to RRG page. I wonder what Tony meant by "analysis of the average number of more specifics if someone does decide to de-aggregate"--do you mean if someone does decide to de-aggregate IPv6 prefix? Lixia PS: I removed IAB from cc-list, as this thread has moved away from RAWS report comments. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 08:23: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 1HTdMI-0008Md-7A; Tue, 20 Mar 2007 08:22:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdMH-0008MY-Az for ram@iab.org; Tue, 20 Mar 2007 08:22:33 -0400 Received: from astrolabe.info.ucl.ac.be ([130.104.229.109] helo=info.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTdME-0004ym-St for ram@iab.org; Tue, 20 Mar 2007 08:22:33 -0400 Received: from [127.0.0.1] (bismarck [130.104.229.58]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id l2KCMGxx003444; Tue, 20 Mar 2007 13:22:17 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <7.0.0.16.2.20070320115246.0143f400@apnic.net> References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C2@XCH-NW-7V2.nw.nos.boeing.com> <91390EE4-E9E6-4F08-96CA-40DEAE5FE5A6@muada.com> <7.0.0.16.2.20070320115246.0143f400@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Luigi Iannone Subject: Re: [RAM] application endpoint identifiers in map-and-encaps schemes Date: Tue, 20 Mar 2007 13:22:30 +0100 X-Mailer: Apple Mail (2.752.2) X-INGI-MailScanner-Information: Please contact the ISP for more information X-INGI-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ram@iab.org, rrg 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 agree with Fred on having addresses associated to interfaces. Identifier need just to indentifity the host. The demultiplexing in =20 upper layers, toward the application, should be an issue tackle in =20 that layers. nevertheless, a node (i.e. an ID) can be reached through several =20 interfaces (if the general case where a node is multihomed) what if we use a relation between ID, interface and IP address, =20 something like: ID @ interface =3D IP address Meaning that the ID and the interface, through which we want to reach =20= the ID, gives us an IP address, or viceversa, an IP address gives us =20 the ID and the interface (kind of reverse lookup). Regards Luigi Le 20-mars-07 =E0 02:14, Geoff Huston a =E9crit : > At 06:24 AM 20/03/2007, Iljitsch van Beijnum wrote: >> On 19-mrt-2007, at 15:03, Templin, Fred L wrote: >> >>> During the RRG meeting on Saturday, Lixia presented a slide >>> suggesting that not only locators and identifiers are desired, >>> but also a possible separation in the identifer in terms of >>> what the physical interface of the end node sees and what the >>> *application endpoint* within the end node sees. I interpret >>> this as follows: >> >> Hm, applications have their own ideas on identification. > > > When you start to consider "identifiers" in a general sense there =20 > is the appreciation that we have managed to devise "identities" =20 > almost everywhere: multi-party applications, application agents, =20 > rendezvous protocols, DNS indirection and referral, mobility =20 > protocols, SHIM6, SCTP, HIP, TCP, etc > > There is no single 'identity" - there are a plethora of such =20 > identities today groupd within a large set of 'realms' of identity, =20= > and I believe that they are an enduring aspect of this environment. =20= > This does not lead me to a "we are heading to a CNLP-liker =20 > destination" conclusion, as there is no single useful encompassing =20 > identifier here, nor do I see any use of value in trying to =20 > construct such a beast! As far as I can see there are, and will be, =20= > many forms of identity and are, and will be, many ways to map =20 > between various identity realms at various levels in the protocol =20 > stack. > > regards, > > Geoff > > > > > > _______________________________________________ > 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 Mar 20 08:26: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 1HTdQI-0002G0-E1; Tue, 20 Mar 2007 08:26:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdQH-0002Fl-0f for ram@iab.org; Tue, 20 Mar 2007 08:26:41 -0400 Received: from xmail03.myhosting.com ([168.144.250.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTdQE-0005j0-NQ for ram@iab.org; Tue, 20 Mar 2007 08:26:40 -0400 Received: (qmail 3415 invoked from network); 20 Mar 2007 12:26:24 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with SMTP for ; 20 Mar 2007 12:26:23 -0000 Message-ID: <45FFD2BA.7050601@cisco.com> Date: Tue, 20 Mar 2007 08:25:30 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: [RAM] dns discover in map-and-encaps schemes References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> In-Reply-To: <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "Templin, Fred L" , rrg , 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 >> 1) source does DNS lookup for the FQDN "dest.example.com". >> 2) source's DNS server is co-resident on the ingress tunnel router >> and performs a lookup in the global DNS for a well-known prefix >> appended to the FQDN suffix, e.g.: "egress.example.com". >> 3) source's DNS server gets back locators for the egress tunnel >> router from the global DNS, then sends an IP-in-IP encapsulated >> RFC4620 Node Information Query asking the egress tunnel router >> to resolve the FQDN "dest.example.com". >> 4) egress tunnel router returns identifers associated with >> "dest.example.com"; ingress tunnel router caches the resolution >> and returns the resolution to the source as response to the >> "real" DNS query. > > What happens when I type "ping " on the source? What if > DNS is down, do I lose global connectivity? What if one of the two > domain names don't exist in DNS? What if network administrators are > totally against making routers DNS servers? What if your ITR is a > low-end router where it can store both the DNS cache and mapping database? > > What I am trying to say is, some things need to go into the network and > some things should just stay out of the network. Don't these same questions/issues apply to the LISP 1.5/2.0/etc schemes which follow LISP 1? Perhaps just replacing "DNS server" with something else? In fact, won't these questions apply to any real locator/id split system, in some form or another? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF/9K6ER27sUhU9OQRAkWWAKCElReSRpcDx8/CTTvEbXYbE/toNACg/DbA 3+RLcA0BsV1F/4Va3pSGAXs= =aaV+ -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 08:28: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 1HTdSD-0003yi-7A; Tue, 20 Mar 2007 08:28:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdSB-0003uk-Tj for ram@iab.org; Tue, 20 Mar 2007 08:28: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 1HTdRv-0006Pa-3T for ram@iab.org; Tue, 20 Mar 2007 08:28:39 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2KCSJ91014182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Mar 2007 05:28:20 -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 l2KCSJFK008618; Tue, 20 Mar 2007 05:28:19 -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 l2KCSJxJ008610; Tue, 20 Mar 2007 05:28:19 -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, 20 Mar 2007 05:28:19 -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] dns discover in map-and-encaps schemes Date: Tue, 20 Mar 2007 05:28:18 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747E0@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] dns discover in map-and-encaps schemes Thread-Index: Acdq2pGucUybeJ5QRjOlN17K5aw1VwADpjcg References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Dino Farinacci" X-OriginalArrivalTime: 20 Mar 2007 12:28:19.0837 (UTC) FILETIME=[3E4BEAD0:01C76AEB] X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ram@iab.org, rrg 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: Dino Farinacci [mailto:dino@cisco.com]=20 > Sent: Tuesday, March 20, 2007 3:29 AM > To: Templin, Fred L > Cc: rrg; ram@iab.org > Subject: Re: [RAM] dns discover in map-and-encaps schemes >=20 > >> What happens when I type "ping " on the source? > > > > Not quite certain what you mean; do you mean ping the source IP > > address from the destination IP address after the source has done > > the DNS mapping for the destination. The intent is the egress tunnel > > router nearest the destination will have cached the source IP to > > locator mapping and so the ping will succeed. >=20 > No, it was a simple statement about what if a host uses addresses to =20 > send packets and not DNS names. >=20 > >> What if DNS is down, do I lose global connectivity? > > > > What happens if the DNS is down in today's Internet? You can >=20 > I can still "[ping,traceroute] ". I can still send =20 > packets, I can still type in "http://192.168.0.1/" in my browser. Everything that works today for IPv4 would work tomorrow for IPvLX for IPvLX nodes that are dual-stacked, which I anticipate would be the normal case. The only nodes that would not be able to do a ping to a global address when the DNS is down would be IPv6-only nodes, but IMHO those would only occur on very small devices on the very extreme edges of the network. > > ping any global IPv4 address and connect to any global IPv4 > > services by specifying an IP address instead of a FQDN, and > > the very same will be true for this scheme. The only thing >=20 > How do you get locators when the DNS is down? When the DNS is down, you will still be able to use IPv4 in the same way we use IPv4 in the Internet today. The draft doesn't explicity say this, but the preferred access method is IPv4, with IPv6 used only for nodes that do not have a FQDN and IPv4 addresses in the global DNS. IPvLX augments the current architecture, it does not compromise it. =20 > > you *won't* be able to do is ping IPv6 addresses and connect > > to IPv6 services that are deeply embedded in distant sites, >=20 > A problem. See above; the situation is no different than for the Internet today. Again, IPvLX augments the existing architecture; it does not compromise it. =20 > >> What if network administrators are totally against making=20 > routers DNS > >> servers? > > > > I want that the function be moved closer to the end devices, and > > not in core routers - but, see more below: >=20 > That still won't make network administrators happier. Howso? Why should the network administrator care if the end node is simply behaving as an ordinary DNS resolver from an outward appearance. That the end node is behaving as a two-faced DNS server on behalf of its downstream-attached devices (and internal virtual hosts) is no business of the network administrator's. 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 Mar 20 08:42: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 1HTdej-0004vu-PR; Tue, 20 Mar 2007 08:41:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdei-0004v3-JN for ram@iab.org; Tue, 20 Mar 2007 08:41:36 -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 1HTdeh-0000uZ-5j for ram@iab.org; Tue, 20 Mar 2007 08:41:36 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2KCfYZU000511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Mar 2007 05:41:34 -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 l2KCfYNn016951; Tue, 20 Mar 2007 05:41:34 -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 l2KCfRcY016697; Tue, 20 Mar 2007 05:41:33 -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, 20 Mar 2007 05:41:33 -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: Tue, 20 Mar 2007 05:41:32 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747E1@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RRG] Initial comments on the LISP proposal Thread-Index: Acdq3Ni8C+Fy7qQ8SqevmsF4cqSXlgADn+Ug References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com><031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747DB@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Dino Farinacci" X-OriginalArrivalTime: 20 Mar 2007 12:41:33.0472 (UTC) FILETIME=[17570200:01C76AED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: rrg , ram@iab.org Subject: [RAM] RE: [RRG] Initial comments on the LISP proposal 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: Dino Farinacci [mailto:dino@cisco.com]=20 > Sent: Tuesday, March 20, 2007 3:45 AM > To: Templin, Fred L > Cc: ram@iab.org; rrg > Subject: Re: [RRG] Initial comments on the LISP proposal >=20 > > Some initial comments on the LISP proposal: >=20 > Thanks for the comments. >=20 > > 1) The ICMP reply that is triggered by the first packet(s) from the > > ITR to the ETR do not seem to contain any information that could >=20 > The Reply goes from the ETR to the ITR. Correct; I had a dyslexic moment. =20 > > help the ITR know that the reply is in fact coming from a > > legitimate on-path ETR. Perhaps add a message digest=20 > (MD5 or other) > > to the ICMP reply so that off-path attacker risks can be=20 > mitigated? >=20 > Security is going to be addressed in the -01 draft. By using nonces =20 > and not accepting unsolicited replies solves most of this. I defer to the threat analysis document and the -01 draft. =20 > > 2) The mechanism is really an open-ended automatic tunneling =20 > > mechanism. > > This means that it will send encapsulated packets=20 > without having =20 > > any > > way of knowing whether a suitably-configured=20 > decapsulator exists on >=20 > This depends on how you do the mapping. If the mapping is pushed and =20 > the ETR registers Locators, then you do know. When you don't know, =20 > the host sends packet a ICMP protocol unreachable message. But if you don't get the ICMPs, it appears as a black hole. > For TE tunnels, you do know because most likely shared-keys will be =20 > used so there will be a bilateral setup of the tunnel. That means, a =20 > technical contract between two ISPs. No problem for configured tunnels, obviously. =20 > > the path. Some systems may refuse to accept encapsulated=20 > packets if > > they do not have at least a tunnel interface configured a priori, >=20 > This depends on the implementation. I plan to not support it this =20 > way. LISP does not require the implementation to configure static =20 > tunnel interfaces in the ITRs and ETRs but strongly=20 > recommends it for =20 > TE-ITRs and TE-ETRs. I'm not concerned about the LISP-enlightened nodes; I'm concerned for the legacy nodes that don't yet implement the scheme and I believe you may be in for some backward-compatibility issues. =20 > > 3) Sending encapsulated packets when there is no way of knowing > > whether there is a suitably-configured decapsulator on the path > > could fail to reach some services, e.g., services that reside > > behind NAT boxes and have "holes" punched in the NAT that only > > recognize unencapsulated packets. >=20 > Same issue when you don't inject your site based route into BGP. I don't understand your response; I was saying that the encapsulated packets are delivered to the NAT box in front of the server, but the NAT has a hole punched through it that only recognizes unencapsulated packets. The service will therefore be unreachable. > > 4) The spec doesn't say for how long the ITR will continue to send > > encapsulated packets when it gets no replies back from an ETR. >=20 > I will fix that, but intentionally left it out so I can get some =20 > implementation experience first before choosing a number. OK, I'll watch for it. > > Will it continue to send the encapsulated packets for the entire > > duration of the flow? If so, this may not work in some cases (see > > above) and will add unnecessary encapsulation overhead in other > > cases. Either way, it seems that legacy systems may suffer before > > the scheme becomes widely deployed. >=20 > We will be using routable-IDs globally only for the first phase. We =20 > plan to have a LISP 3.0 solution soon so we never have routable IDs. =20 > That is the best direction to pursue. I'll watch for that too. > The ultimate goal should be to address all sites with PI blocks and =20 > not have those blocks injected into BGP. We really need to get to =20 > this goal as soon as possible (for both IPv4 and IPv6). I'll agree with that. > > 5) There is also the issue of unnessary IP fragmentation on the path > > when the ITR is not careful about the size of the=20 > tunneled packets > > it sends. >=20 > Yep, a problem with any tunneling design. Fixable with a suitable tunnel path MTU assurance mechanism. =20 > Thanks again. I will get numbers in the spec in about a month or so. OK - Fred fred.l.templin@boeing.com > Dino=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 08:44:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdhm-0001GH-2q; Tue, 20 Mar 2007 08:44:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdhj-00014i-5K for ram@iab.org; Tue, 20 Mar 2007 08:44:43 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTdhh-0001dm-Ro for ram@iab.org; Tue, 20 Mar 2007 08:44:43 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2007 13:44:36 +0100 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 l2KCiag2004099; Tue, 20 Mar 2007 13:44:36 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2KCiDll015454; Tue, 20 Mar 2007 12:44:31 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 13:44:26 +0100 Received: from [10.0.1.235] ([10.61.64.228]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 13:44:26 +0100 In-Reply-To: <18C09EFB-05BE-4170-9D16-8120A22311EB@cs.ucla.edu> References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> <20070319034300.GA21041@vaf-lnx1.cisco.com> <18C09EFB-05BE-4170-9D16-8120A22311EB@cs.ucla.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <317A019F-B8A4-4B89-AD87-0892548D7C6D@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Tue, 20 Mar 2007 13:44:24 +0100 To: Lixia Zhang X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 12:44:26.0508 (UTC) FILETIME=[7E7A34C0:01C76AED] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=632; t=1174394676; x=1175258676; c=relaxed/simple; s=amsdkim2001; 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]=20Re=3A=20Impending=20publication=3A=20draft-ia b-raws-report-01.txt |Sender:=20; bh=R3hKRtonZnfxvPxW9G0MxFmgGqjwxYYxRlRRs3hCsd4=; b=dHNaXHc0NAVExQraMf46pdmpKoDG+gYEFkZdGgqlxtKOx11hclPAmHH4+hfh3ANbXVNgNWYf sE0uuLuicpLwWY9D6KcZb3aTsjDCivqGGHb/H+zTqYypVDuAVd3Rdb95; Authentication-Results: ams-dkim-2; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/amsdkim2001 verified; ); 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 On Mar 20, 2007, at 1:05 PM, Lixia Zhang wrote: >> How big of a problem this is, I can't say. I don't know if anyone >> has done any kind of analysis of the average number of more >> specifics if someone does decide to de-aggregate. > > > > I wonder what Tony meant by "analysis of the average number of more > specifics if someone does decide to de-aggregate"--do you mean if > someone does decide to de-aggregate IPv6 prefix? Lixia, Specifically what I'd like to see is for aggregates that have more specifics present, what is the average number of those more specifics per aggregate? Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 08:45: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 1HTdi0-0001yZ-VK; Tue, 20 Mar 2007 08:45:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdhz-0001uw-Qi for ram@iab.org; Tue, 20 Mar 2007 08:44:59 -0400 Received: from xmail01.myhosting.com ([168.144.250.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTdhu-0001h0-GA for ram@iab.org; Tue, 20 Mar 2007 08:44:59 -0400 Received: (qmail 9433 invoked from network); 20 Mar 2007 12:44:53 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail01.myhosting.com (qmail-ldap-1.03) with SMTP for ; 20 Mar 2007 12:44:53 -0000 Message-ID: <45FFD70F.4000702@cisco.com> Date: Tue, 20 Mar 2007 08:43:59 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] dns discover in map-and-encaps schemes References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <45FFD2BA.7050601@cisco.com> In-Reply-To: <45FFD2BA.7050601@cisco.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: rrg 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 >>> 1) source does DNS lookup for the FQDN "dest.example.com". >>> 2) source's DNS server is co-resident on the ingress tunnel router >>> and performs a lookup in the global DNS for a well-known prefix >>> appended to the FQDN suffix, e.g.: "egress.example.com". >>> 3) source's DNS server gets back locators for the egress tunnel >>> router from the global DNS, then sends an IP-in-IP encapsulated >>> RFC4620 Node Information Query asking the egress tunnel router >>> to resolve the FQDN "dest.example.com". >>> 4) egress tunnel router returns identifers associated with >>> "dest.example.com"; ingress tunnel router caches the resolution >>> and returns the resolution to the source as response to the >>> "real" DNS query. >> What happens when I type "ping " on the source? What if >> DNS is down, do I lose global connectivity? What if one of the two >> domain names don't exist in DNS? What if network administrators are >> totally against making routers DNS servers? What if your ITR is a >> low-end router where it can store both the DNS cache and mapping database? > >> What I am trying to say is, some things need to go into the network and >> some things should just stay out of the network. > > Don't these same questions/issues apply to the LISP 1.5/2.0/etc schemes > which follow LISP 1? Perhaps just replacing "DNS server" with something > else? > > In fact, won't these questions apply to any real locator/id split > system, in some form or another? To wit: In a slightly later email: > We will be using routable-IDs globally only for the first phase. > We plan to have a LISP 3.0 solution soon so we never have routable IDs. > That is the best direction to pursue. What happens if I "ping ," and the LISP server is down? I'm not saying we shouldn't consider a case where nothing happens, I'm simply saying this brings up a fundamental point we need to consider in all cases of locator/id split, including LISP 3.0. Is it okay for the network to fail when some set of network reachable servers, or some network accessible service, fails? If it is, then any number of schemes will work for a locator/id split, and we should consider the end result of any system, rather than using one step here, and another step there. Perhaps it's best to: 1. Consider the problem of reachability being predicated on a service. This is a fundamental change in architecture, and we should consider it as a correlation, one of the possible negative side effects, of a locator/id split of any type. 2. Consider the end result of any given system. Right now, we're seeing a lot of things thrown out, where someone says: "In version 1, we do this, in version 2, we do that, in version 3, we do the other thing." This is very confusing, and makes for a lot of shifting conversation--more heat than light, in many cases. Start from where you want to be, and let's consider the final end point. If that looks good, then let's figure out what the transition mechanisms are. I think we might be working the wrong way around, looking at proposals to solve a problem, and not considering the tradeoffs and possible problems we're going to be creating. Further, we're looking at systems that have several stages, and sometimes comparing stage 1 of system x against stage 2 of system y, which is then countered by comparing stage 1 of system y against stage 2 of system y. Let's stick to final results, so everything is compared on a level playing field. Just a thought. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFF/9cPER27sUhU9OQRApGGAKDwwHKhYkxniDld7Q0Prsldw0yn5QCWLrJw CJr0iC8ILBHBoSzsIJJc1g== =6PxT -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 08:59: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 1HTdty-00014X-Ct; Tue, 20 Mar 2007 08:57:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdtw-0000zB-QO for ram@iab.org; Tue, 20 Mar 2007 08:57:20 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTdtr-0004SF-Mk for ram@iab.org; Tue, 20 Mar 2007 08:57:20 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by kremlin.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 20 Mar 2007 05:57:15 -0700 X-IronPort-AV: i="4.14,304,1170662400"; d="scan'208"; a="673061422:sNHT33820436" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l2KCvBJ98098; Tue, 20 Mar 2007 05:57:11 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200703201257.l2KCvBJ98098@merlot.juniper.net> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt In-Reply-To: Your message of "Mon, 19 Mar 2007 13:11:28 EDT." <20070319171128.1B45D86AF1@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46524.1174395431.1@juniper.net> Date: Tue, 20 Mar 2007 05:57:11 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: iab@ietf.org, 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 Noel, > > From: Leslie Daigle > > > the purpose of this document is strictly and uniquely to document the > > discussion that occurred at the workshop. > > ... > > Comments that help clarify the text as a representation of what was > > discussed at the event will be gratefully accepted for the document. > > Every else -- is input to the current discussions > > That's a logical position to take, but if so, the workshop report needs to > carry a clear disclaimer, up front, that some of the conclusions drawn in it > are now known to be incorrect. That will alert the unwary not to put undue > reliance on any statements therein. Agreed. That is why I think the draft should include the text proposed by Ross. Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 08:59: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 1HTdun-0001Oy-9L; Tue, 20 Mar 2007 08:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTdum-0001Os-OS for ram@iab.org; Tue, 20 Mar 2007 08:58:12 -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 1HTduX-0004b8-T3 for ram@iab.org; Tue, 20 Mar 2007 08:58:12 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2KCvpAJ027587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Mar 2007 07:57:52 -0500 (CDT) 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 l2KCvpdM009227; Tue, 20 Mar 2007 07:57:51 -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 l2KCvZhL008766; Tue, 20 Mar 2007 07:57:51 -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); Tue, 20 Mar 2007 05:57: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] what we should be working on Date: Tue, 20 Mar 2007 05:57:36 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747E3@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <03EDD675-CD47-4145-AF95-76EE6C7218D1@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] what we should be working on Thread-Index: Acdq3os1aVw5SViuQFKk7NaPeGzb/QAD2vPg References: <45F94921.7010707@piuha.net><45FC10FD.2060507@piuha.net><0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <03EDD675-CD47-4145-AF95-76EE6C7218D1@muada.com> From: "Templin, Fred L" To: "Iljitsch van Beijnum" , "Tony Li" X-OriginalArrivalTime: 20 Mar 2007 12:57:37.0391 (UTC) FILETIME=[55E15FF0:01C76AEF] 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 Ethernet jumbo frames may not be standardized, but they are real and they do appear in widely-deployed products. As a layer 3 mechanism, our job is not to standardize jumbo frames or legislate how they should be deployed; our job is only to take best advantage of the resources the network is offering us. Here are some links on raising the Internet MTU and ethernet jumbo frames: http://www.psc.edu/~mathis/MTU/ http://sd.wareonearth.com/~phil/jumbo.html http://darkwing.uoregon.edu/~joe/jumbo-clean-gear.html Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > Sent: Tuesday, March 20, 2007 3:55 AM > To: Tony Li > Cc: ram@iab.org > Subject: Re: [RAM] what we should be working on >=20 > On 20-mrt-2007, at 11:31, Tony Li wrote: >=20 > >> Does 1000bt (like in many/most 'new' computers 10/100/1000=20 > copper) do > >> jumbo-frames already? So is this a problem? >=20 > > AFAIK, jumbo frames are *not* standardized and have been=20 > repeatedly =20 > > rejected by the IEEE. The IETF is less than willing to=20 > step on the =20 > > IEEE's turf and so has historically declined to make its own =20 > > standards in this area. >=20 > Jumboframe capability of some sort is very common, but certainly not =20 > universal in NICs that support gigabit ethernet, with or without 10 =20 > and 100 Mbps ethernet capability. There is no common=20 > jumboframe size. =20 > I've seen stuff in the 1500 - 2048 byte range and 9000, 9216, 16384 =20 > and 64000 bytes. Note that jumboframes must invariably be enabled =20 > manually. >=20 > Not being privvy to IEEE internals, I assume the problem the=20 > IEEE has =20 > with changing the 802.3 maximum packet size is twofold: >=20 > 1. Existing 802.3 standards mandate 1500 bytes and there is no =20 > support for fragmentation so if a newer standard supports larger =20 > packets, it won't be possible to internetwork equipment adhering to =20 > the old and new standards because the old stuff can't handle the 1500=20 > + packets. (The graybeards among us may at this point fondly think =20 > back to bridging between ethernet and FDDI.) >=20 > 2. 802.3 has a length field where Ethernet II has a type field. The =20 > type and length values don't clash for ~1500 bytes but they do for =20 > larger packets. >=20 > Argument 1. disappears when we fix this at the IP layer because =20 > unlike ethernet, IP can fragment. Argument 2. is irrelevant for IP =20 > because we use Ethernet II and not 802.3 encapsulation. >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 09:18:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeCU-0003OY-PA; Tue, 20 Mar 2007 09:16:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeCT-0003Lc-Er for ram@iab.org; Tue, 20 Mar 2007 09:16:29 -0400 Received: from [80.86.78.228] (helo=smtp.testbed.se) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTeCM-0002Zz-3h for ram@iab.org; Tue, 20 Mar 2007 09:16:29 -0400 Received: from dhcp-10d8.ietf68.org ([130.129.16.216]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1HTeBr-0001xR-EE; Tue, 20 Mar 2007 14:16:12 +0100 Message-ID: <45FFDE81.8030903@pi.se> Date: Tue, 20 Mar 2007 14:15:45 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt References: <200703201257.l2KCvBJ98098@merlot.juniper.net> In-Reply-To: <200703201257.l2KCvBJ98098@merlot.juniper.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: iab@ietf.org, Noel Chiappa , 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 All, I'm not really against adding the text proposed by Ross, but I guess you could include something like that as soon as you have written anything down. "The sky is (no, no, no, not falling ;) ) blue". Don't take into consideration that once every 24 hours it turns black (or very deep blue). It is the nature of anything written, that with time there will be "increased understanding" especially if there is "ongoing work", often this is the reason to write it down. /Loa Yakov Rekhter wrote: > Noel, > >> > From: Leslie Daigle >> >> > the purpose of this document is strictly and uniquely to document the >> > discussion that occurred at the workshop. >> > ... >> > Comments that help clarify the text as a representation of what was >> > discussed at the event will be gratefully accepted for the document. >> > Every else -- is input to the current discussions >> >> That's a logical position to take, but if so, the workshop report needs to >> carry a clear disclaimer, up front, that some of the conclusions drawn in it >> are now known to be incorrect. That will alert the unwary not to put undue >> reliance on any statements therein. > > Agreed. That is why I think the draft should include the text > proposed by Ross. > > Yakov. > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 09:31: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 1HTePH-0008LS-61; Tue, 20 Mar 2007 09:29:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTePG-0008KU-6f for ram@iab.org; Tue, 20 Mar 2007 09:29:42 -0400 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTePD-0006l0-MV for ram@iab.org; Tue, 20 Mar 2007 09:29:42 -0400 Received: from [130.129.16.84] (dhcp-1054.ietf68.org [130.129.16.84]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id l2KDTYvB019076; Tue, 20 Mar 2007 06:29:34 -0700 (PDT) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747E0@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747E0@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66755836-34A1-4375-AE21-75164CE3147E@cs.ucla.edu> Content-Transfer-Encoding: 7bit From: Lixia Zhang Subject: Re: [RRG] RE: [RAM] dns discover in map-and-encaps schemes Date: Tue, 20 Mar 2007 06:29:31 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: ram@iab.org, rrg 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 not a reply to your msg but a question of where you'd like to direct the discussion to: I am very sure I'm not the only on both lists and found double-copies on every msg confusing (given how far I'm behind, this does not help) I strongly discourage any future posts going to both ram and rrg, given the potential high overlap in membership between the two. One can easily send a note to list 1 telling others that he has posted an important thing to list 2. Fred you started this double-list posting, which list would you like to continue on? Personally it seems to me mostly belonging to RAM, though you may feel otherwise. On Mar 20, 2007, at 5:28 AM, Templin, Fred L wrote: >> -----Original Message----- >> From: Dino Farinacci [mailto:dino@cisco.com] >> Sent: Tuesday, March 20, 2007 3:29 AM >> To: Templin, Fred L >> Cc: rrg; ram@iab.org >> Subject: Re: [RAM] dns discover in map-and-encaps schemes >> >>>> What happens when I type "ping " on the source? >>> >>> Not quite certain what you mean; do you mean ping the source IP >>> address from the destination IP address after the source has done >>> the DNS mapping for the destination. The intent is the egress tunnel >>> router nearest the destination will have cached the source IP to >>> locator mapping and so the ping will succeed. >> >> No, it was a simple statement about what if a host uses addresses to >> send packets and not DNS names. >> >>>> What if DNS is down, do I lose global connectivity? >>> >>> What happens if the DNS is down in today's Internet? You can >> >> I can still "[ping,traceroute] ". I can still send >> packets, I can still type in "http://192.168.0.1/" in my browser. > > Everything that works today for IPv4 would work tomorrow for IPvLX > for IPvLX nodes that are dual-stacked, which I anticipate would be > the normal case. The only nodes that would not be able to do a ping > to a global address when the DNS is down would be IPv6-only nodes, > but IMHO those would only occur on very small devices on the very > extreme edges of the network. > >>> ping any global IPv4 address and connect to any global IPv4 >>> services by specifying an IP address instead of a FQDN, and >>> the very same will be true for this scheme. The only thing >> >> How do you get locators when the DNS is down? > > When the DNS is down, you will still be able to use IPv4 in the > same way we use IPv4 in the Internet today. The draft doesn't > explicity say this, but the preferred access method is IPv4, > with IPv6 used only for nodes that do not have a FQDN and IPv4 > addresses in the global DNS. IPvLX augments the current > architecture, it does not compromise it. > >>> you *won't* be able to do is ping IPv6 addresses and connect >>> to IPv6 services that are deeply embedded in distant sites, >> >> A problem. > > See above; the situation is no different than for the Internet > today. Again, IPvLX augments the existing architecture; it does > not compromise it. > >>>> What if network administrators are totally against making >> routers DNS >>>> servers? >>> >>> I want that the function be moved closer to the end devices, and >>> not in core routers - but, see more below: >> >> That still won't make network administrators happier. > > Howso? Why should the network administrator care if the end > node is simply behaving as an ordinary DNS resolver from an > outward appearance. That the end node is behaving as a > two-faced DNS server on behalf of its downstream-attached > devices (and internal virtual hosts) is no business of the > network administrator's. > > Fred > fred.l.templin@boeing.com > > -- > to unsubscribe send a message to rrg-request@psg.com with the > word 'unsubscribe' in a single line as the message text body. > archive: & ftp://psg.com/pub/lists/rrg _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 10:36: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 1HTfPk-0004wL-Va; Tue, 20 Mar 2007 10:34:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTfPk-0004vr-3F for ram@iab.org; Tue, 20 Mar 2007 10:34:16 -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 1HTfPQ-0004fb-FL for ram@iab.org; Tue, 20 Mar 2007 10:34:16 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2KEXseY025177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Mar 2007 07:33:54 -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 l2KEXr0D001205; Tue, 20 Mar 2007 07:33:53 -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 l2KEXqBg001125; Tue, 20 Mar 2007 07:33:53 -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, 20 Mar 2007 07:33: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: [RRG] RE: [RAM] dns discover in map-and-encaps schemes Date: Tue, 20 Mar 2007 07:33:48 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747E7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <66755836-34A1-4375-AE21-75164CE3147E@cs.ucla.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RRG] RE: [RAM] dns discover in map-and-encaps schemes Thread-Index: Acdq884n9CJwpkIoTnaR01avd8YrbwAB/1Ig References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747E0@XCH-NW-7V2.nw.nos.boeing.com> <66755836-34A1-4375-AE21-75164CE3147E@cs.ucla.edu> From: "Templin, Fred L" To: "Lixia Zhang" X-OriginalArrivalTime: 20 Mar 2007 14:33:49.0120 (UTC) FILETIME=[C6195400:01C76AFC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: ram@iab.org, rrg 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 Lixia, and thanks for the guidance on this. I certainly agree with minimizing the clutter, and am happy to move to just one list. I don't have a preference as to which one, so I defer to your judgement and will use just one list from now on. But, a procedural question: how can we decide which is the appropriate list on a case-per-case basis? (I think we still have all three of the ram, rrg, and architecture-discuss lists to choose from?) Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Lixia Zhang [mailto:lixia@CS.UCLA.EDU]=20 > Sent: Tuesday, March 20, 2007 6:30 AM > To: Templin, Fred L > Cc: Dino Farinacci; rrg; ram@iab.org > Subject: Re: [RRG] RE: [RAM] dns discover in map-and-encaps schemes >=20 > this is not a reply to your msg but a question of where you'd=20 > like to =20 > direct the discussion to: I am very sure I'm not the only on both =20 > lists and found double-copies on every msg confusing (given how far =20 > I'm behind, this does not help) >=20 > I strongly discourage any future posts going to both ram and rrg, =20 > given the potential high overlap in membership between the two. One =20 > can easily send a note to list 1 telling others that he has=20 > posted an =20 > important thing to list 2. >=20 > Fred you started this double-list posting, which list would you like =20 > to continue on? > Personally it seems to me mostly belonging to RAM, though you may =20 > feel otherwise. >=20 > On Mar 20, 2007, at 5:28 AM, Templin, Fred L wrote: >=20 > >> -----Original Message----- > >> From: Dino Farinacci [mailto:dino@cisco.com] > >> Sent: Tuesday, March 20, 2007 3:29 AM > >> To: Templin, Fred L > >> Cc: rrg; ram@iab.org > >> Subject: Re: [RAM] dns discover in map-and-encaps schemes > >> > >>>> What happens when I type "ping " on the source? > >>> > >>> Not quite certain what you mean; do you mean ping the source IP > >>> address from the destination IP address after the source has done > >>> the DNS mapping for the destination. The intent is the=20 > egress tunnel > >>> router nearest the destination will have cached the source IP to > >>> locator mapping and so the ping will succeed. > >> > >> No, it was a simple statement about what if a host uses=20 > addresses to > >> send packets and not DNS names. > >> > >>>> What if DNS is down, do I lose global connectivity? > >>> > >>> What happens if the DNS is down in today's Internet? You can > >> > >> I can still "[ping,traceroute] ". I can still send > >> packets, I can still type in "http://192.168.0.1/" in my browser. > > > > Everything that works today for IPv4 would work tomorrow for IPvLX > > for IPvLX nodes that are dual-stacked, which I anticipate would be > > the normal case. The only nodes that would not be able to do a ping > > to a global address when the DNS is down would be IPv6-only nodes, > > but IMHO those would only occur on very small devices on the very > > extreme edges of the network. > > > >>> ping any global IPv4 address and connect to any global IPv4 > >>> services by specifying an IP address instead of a FQDN, and > >>> the very same will be true for this scheme. The only thing > >> > >> How do you get locators when the DNS is down? > > > > When the DNS is down, you will still be able to use IPv4 in the > > same way we use IPv4 in the Internet today. The draft doesn't > > explicity say this, but the preferred access method is IPv4, > > with IPv6 used only for nodes that do not have a FQDN and IPv4 > > addresses in the global DNS. IPvLX augments the current > > architecture, it does not compromise it. > > > >>> you *won't* be able to do is ping IPv6 addresses and connect > >>> to IPv6 services that are deeply embedded in distant sites, > >> > >> A problem. > > > > See above; the situation is no different than for the Internet > > today. Again, IPvLX augments the existing architecture; it does > > not compromise it. > > > >>>> What if network administrators are totally against making > >> routers DNS > >>>> servers? > >>> > >>> I want that the function be moved closer to the end devices, and > >>> not in core routers - but, see more below: > >> > >> That still won't make network administrators happier. > > > > Howso? Why should the network administrator care if the end > > node is simply behaving as an ordinary DNS resolver from an > > outward appearance. That the end node is behaving as a > > two-faced DNS server on behalf of its downstream-attached > > devices (and internal virtual hosts) is no business of the > > network administrator's. > > > > Fred > > fred.l.templin@boeing.com > > > > -- > > to unsubscribe send a message to rrg-request@psg.com with the > > word 'unsubscribe' in a single line as the message text body. > > archive: & ftp://psg.com/pub/lists/rrg >=20 >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 10:36: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 1HTfO4-0008PC-0T; Tue, 20 Mar 2007 10:32:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTfO3-0008Mt-6L for ram@iab.org; Tue, 20 Mar 2007 10:32:31 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTfNX-0004RF-AI for ram@iab.org; Tue, 20 Mar 2007 10:32:31 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D87C486ADD; Tue, 20 Mar 2007 10:31:58 -0400 (EDT) To: ram@iab.org, rrg@psg.com Subject: Re: [RAM] dns discover in map-and-encaps schemes Message-Id: <20070320143158.D87C486ADD@mercury.lcs.mit.edu> Date: Tue, 20 Mar 2007 10:31:58 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: jnc@mercury.lcs.mit.edu 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: Russ White > What happens if I "ping ," and the LISP server is down? Umm, pretty much the same thing that happens when you click on a URL and the DNS server(s) for that domain are down/unreachable... :-) But to be serious about it: > Is it okay for the network to fail when some set of network reachable > servers, or some network accessible service, fails? ... > Consider the problem of reachability being predicated on a service. > This is a fundamental change in architecture Here is a slightly extended design-philosophical soliloquy on this general topic (and maybe some of this was already in your mind when you sent that message out...): It is certainly true that systems which i) don't modify the hosts at all and ii) introduce a new location-namespace underneath the current internetwork layer, thereby iii) turning the current internetwork "addresses" into names which are basically purely identity, and therefore iv) require mapping into location-names to be usable for forwarding traffic, are a significant architectural change - and one with new failure modes. I don't necessarily consider the extra complexity (and *necessarily* consequent extra potential failure modes) to be necessarily bad. Abraham Lincoln was once asked how long a man's legs should be; his reply was "long enough to reach the ground". So too with complexity in large information systems. You need as much as you need. And you need more complexity as the system gets bigger. [Anyone who doubts that this is a general law should consider, for example, the anatomy of a single-celled organism versus your average mammal: the mammal has all sorts of specialized sub-systems - e.g. the circulatory system, which has its own specialized failure modes such as blockages caused by a variety of buildups - which the smaller - and simpler - organism lacks. (And no matter which side of the evolution/design split you fall on, you have to agree that something pretty intense decided it *really needed* that extra complexity! :-)] So the questions really are: - Do we need this extra complexity (and necessarily consequent new failure modes), and - If so, how do we deal with the problems this extra complexity brings, e.g. how to protect against those failure modes, how to make sure we can debug/fix failures (i.e. operations/maintainence issues), etc. If our goals are i) to not modify hosts, and ii) add another namespace - both goals which I think are reasonable - then *necessarily*, something out there is going to have to do mappings. So now the only question left is "how to deal with the problems this inventably brings, such as new failure modes". Now, that's a reasonably well-understood field. Systems designers have been dealing with these issues for many decades now. Some of the tools we use to do this are: - a) Make sure we don't have any dependency loops (i.e. subsystem A depends on subsystem B which depends on subsystem A) - b) Make sure our debugging tools for debugging system Y (which depends on X and below) only depend on X and below, and make sure we have direct access to X and below, without going through Y - c) In a distributed system, use replication to ensure availability These are tools we already use - e.g. when you type IP addresses directly into a tool, without using DNS, you're doing b); and DNS itself uses c) to increase its robustness. And there are more techniques, I won't go into a long spiel on them - the point is we know how to do this. And while I'm in this general area, I'd like to rant a bit about people who assume addresses, and routing (path-selection) mechanisms, are somehow fundamentally different - more reliable, more trustworthy, more available, more *special* - from every other mechanism (e.g. mapping services). They aren't. It kind of drives me batty when people assume raw IPvN-style addresses are somehow fundamentally different from all other possible mechanisms, that they have some ethereal quality which necessarily makes them more reliable, more dependable, than all other mechanisms. They aren't. Path-selection and forwarding are also complex distributed system with all sorts of failure modes. The people who designed them are fully aware of how critical they are, and have used a lot of ingenuity, and in many cases some pretty complex and heavy-weight mechanisms (try read the IS-IS or OSPF specs) to make sure they *are* reliable and dependable. But they accepted that complexity to make the *overall* operation one that one can rely on. So, circling back to where we started, given a certain goal-set (not modify hosts, and add another namespace) then something out there is going to have to do mappings; and we'll just have to deal with the problems this inventably brings: but I think we know how. > this brings up a fundamental point we need to consider in all cases of > locator/id split ... > ... reachability being predicated on a service ... one of the possible > negative side effects, of a locator/id split of any type. If you get to change the hosts, you can avoid this problem in a number of ways. One is to say that *all* DNS entries have to contain both location and identity names, and the lookup returns them both, and they travel around forever thereafter as a tuple (unless the binding is modified in some suitably-secure way). Another is to keep the existing DNS (returns location-name only), and pass identities in the connection-open packets in each direction. Etc, etc... Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 10:36: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 1HTfQA-0005KW-Q3; Tue, 20 Mar 2007 10:34:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTfQ9-0005I9-5g for ram@iab.org; Tue, 20 Mar 2007 10:34:41 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTfPt-0004iO-UC for ram@iab.org; Tue, 20 Mar 2007 10:34:41 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 20 Mar 2007 07:34:25 -0700 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 l2KEYPcv032000; Tue, 20 Mar 2007 07:34:25 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l2KEYLEi012225; Tue, 20 Mar 2007 14:34:21 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, 20 Mar 2007 07:34:20 -0700 Received: from [130.129.17.126] ([10.21.146.223]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 07:34:20 -0700 In-Reply-To: <45FFD2BA.7050601@cisco.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <45FFD2BA.7050601@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <004F88D9-FFC8-4EA2-96DD-A497EFCCC808@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] dns discover in map-and-encaps schemes Date: Tue, 20 Mar 2007 07:34:18 -0700 To: Russ White X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 14:34:20.0396 (UTC) FILETIME=[D8BDAAC0:01C76AFC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=852; t=1174401265; x=1175265265; 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]=20dns=20discover=20in=20map-and-encaps=20scheme s |Sender:=20; bh=4BCkgFvGcxaalGVew8L7WmiJS2cDVvx1kQqD9PmC/70=; b=PAT+DY0U4AeYIBldkJwelKv257Bp+qjEqRo4cUl1yWhs2zs51b2yAWmxrAs11X0HUb02R8ON JHWhrmzxJpNgAAMA2Hw3Po6Q9eAkfkR0zhZMPbVLme3bNHkj+YT/ppRe; 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: "Templin, Fred L" , rrg , 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 >> What happens when I type "ping " on the source? >> What if >> DNS is down, do I lose global connectivity? What if one of the two >> domain names don't exist in DNS? What if network administrators are >> totally against making routers DNS servers? What if your ITR is a >> low-end router where it can store both the DNS cache and mapping >> database? >> >> What I am trying to say is, some things need to go into the >> network and >> some things should just stay out of the network. > > Don't these same questions/issues apply to the LISP 1.5/2.0/etc > schemes > which follow LISP 1? Perhaps just replacing "DNS server" with > something > else? Exactly why I asked the questions. > In fact, won't these questions apply to any real locator/id split > system, in some form or another? Yep. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 10:36: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 1HTfPk-0004wL-Va; Tue, 20 Mar 2007 10:34:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTfPk-0004vr-3F for ram@iab.org; Tue, 20 Mar 2007 10:34:16 -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 1HTfPQ-0004fb-FL for ram@iab.org; Tue, 20 Mar 2007 10:34:16 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2KEXseY025177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Mar 2007 07:33:54 -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 l2KEXr0D001205; Tue, 20 Mar 2007 07:33:53 -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 l2KEXqBg001125; Tue, 20 Mar 2007 07:33:53 -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, 20 Mar 2007 07:33: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: [RRG] RE: [RAM] dns discover in map-and-encaps schemes Date: Tue, 20 Mar 2007 07:33:48 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747E7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <66755836-34A1-4375-AE21-75164CE3147E@cs.ucla.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RRG] RE: [RAM] dns discover in map-and-encaps schemes Thread-Index: Acdq884n9CJwpkIoTnaR01avd8YrbwAB/1Ig References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747E0@XCH-NW-7V2.nw.nos.boeing.com> <66755836-34A1-4375-AE21-75164CE3147E@cs.ucla.edu> From: "Templin, Fred L" To: "Lixia Zhang" X-OriginalArrivalTime: 20 Mar 2007 14:33:49.0120 (UTC) FILETIME=[C6195400:01C76AFC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: ram@iab.org, rrg 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 Lixia, and thanks for the guidance on this. I certainly agree with minimizing the clutter, and am happy to move to just one list. I don't have a preference as to which one, so I defer to your judgement and will use just one list from now on. But, a procedural question: how can we decide which is the appropriate list on a case-per-case basis? (I think we still have all three of the ram, rrg, and architecture-discuss lists to choose from?) Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Lixia Zhang [mailto:lixia@CS.UCLA.EDU]=20 > Sent: Tuesday, March 20, 2007 6:30 AM > To: Templin, Fred L > Cc: Dino Farinacci; rrg; ram@iab.org > Subject: Re: [RRG] RE: [RAM] dns discover in map-and-encaps schemes >=20 > this is not a reply to your msg but a question of where you'd=20 > like to =20 > direct the discussion to: I am very sure I'm not the only on both =20 > lists and found double-copies on every msg confusing (given how far =20 > I'm behind, this does not help) >=20 > I strongly discourage any future posts going to both ram and rrg, =20 > given the potential high overlap in membership between the two. One =20 > can easily send a note to list 1 telling others that he has=20 > posted an =20 > important thing to list 2. >=20 > Fred you started this double-list posting, which list would you like =20 > to continue on? > Personally it seems to me mostly belonging to RAM, though you may =20 > feel otherwise. >=20 > On Mar 20, 2007, at 5:28 AM, Templin, Fred L wrote: >=20 > >> -----Original Message----- > >> From: Dino Farinacci [mailto:dino@cisco.com] > >> Sent: Tuesday, March 20, 2007 3:29 AM > >> To: Templin, Fred L > >> Cc: rrg; ram@iab.org > >> Subject: Re: [RAM] dns discover in map-and-encaps schemes > >> > >>>> What happens when I type "ping " on the source? > >>> > >>> Not quite certain what you mean; do you mean ping the source IP > >>> address from the destination IP address after the source has done > >>> the DNS mapping for the destination. The intent is the=20 > egress tunnel > >>> router nearest the destination will have cached the source IP to > >>> locator mapping and so the ping will succeed. > >> > >> No, it was a simple statement about what if a host uses=20 > addresses to > >> send packets and not DNS names. > >> > >>>> What if DNS is down, do I lose global connectivity? > >>> > >>> What happens if the DNS is down in today's Internet? You can > >> > >> I can still "[ping,traceroute] ". I can still send > >> packets, I can still type in "http://192.168.0.1/" in my browser. > > > > Everything that works today for IPv4 would work tomorrow for IPvLX > > for IPvLX nodes that are dual-stacked, which I anticipate would be > > the normal case. The only nodes that would not be able to do a ping > > to a global address when the DNS is down would be IPv6-only nodes, > > but IMHO those would only occur on very small devices on the very > > extreme edges of the network. > > > >>> ping any global IPv4 address and connect to any global IPv4 > >>> services by specifying an IP address instead of a FQDN, and > >>> the very same will be true for this scheme. The only thing > >> > >> How do you get locators when the DNS is down? > > > > When the DNS is down, you will still be able to use IPv4 in the > > same way we use IPv4 in the Internet today. The draft doesn't > > explicity say this, but the preferred access method is IPv4, > > with IPv6 used only for nodes that do not have a FQDN and IPv4 > > addresses in the global DNS. IPvLX augments the current > > architecture, it does not compromise it. > > > >>> you *won't* be able to do is ping IPv6 addresses and connect > >>> to IPv6 services that are deeply embedded in distant sites, > >> > >> A problem. > > > > See above; the situation is no different than for the Internet > > today. Again, IPvLX augments the existing architecture; it does > > not compromise it. > > > >>>> What if network administrators are totally against making > >> routers DNS > >>>> servers? > >>> > >>> I want that the function be moved closer to the end devices, and > >>> not in core routers - but, see more below: > >> > >> That still won't make network administrators happier. > > > > Howso? Why should the network administrator care if the end > > node is simply behaving as an ordinary DNS resolver from an > > outward appearance. That the end node is behaving as a > > two-faced DNS server on behalf of its downstream-attached > > devices (and internal virtual hosts) is no business of the > > network administrator's. > > > > Fred > > fred.l.templin@boeing.com > > > > -- > > to unsubscribe send a message to rrg-request@psg.com with the > > word 'unsubscribe' in a single line as the message text body. > > archive: & ftp://psg.com/pub/lists/rrg >=20 >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 10:36: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 1HTfO4-0008PC-0T; Tue, 20 Mar 2007 10:32:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTfO3-0008Mt-6L for ram@iab.org; Tue, 20 Mar 2007 10:32:31 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTfNX-0004RF-AI for ram@iab.org; Tue, 20 Mar 2007 10:32:31 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D87C486ADD; Tue, 20 Mar 2007 10:31:58 -0400 (EDT) To: ram@iab.org, rrg@psg.com Subject: Re: [RAM] dns discover in map-and-encaps schemes Message-Id: <20070320143158.D87C486ADD@mercury.lcs.mit.edu> Date: Tue, 20 Mar 2007 10:31:58 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: jnc@mercury.lcs.mit.edu 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: Russ White > What happens if I "ping ," and the LISP server is down? Umm, pretty much the same thing that happens when you click on a URL and the DNS server(s) for that domain are down/unreachable... :-) But to be serious about it: > Is it okay for the network to fail when some set of network reachable > servers, or some network accessible service, fails? ... > Consider the problem of reachability being predicated on a service. > This is a fundamental change in architecture Here is a slightly extended design-philosophical soliloquy on this general topic (and maybe some of this was already in your mind when you sent that message out...): It is certainly true that systems which i) don't modify the hosts at all and ii) introduce a new location-namespace underneath the current internetwork layer, thereby iii) turning the current internetwork "addresses" into names which are basically purely identity, and therefore iv) require mapping into location-names to be usable for forwarding traffic, are a significant architectural change - and one with new failure modes. I don't necessarily consider the extra complexity (and *necessarily* consequent extra potential failure modes) to be necessarily bad. Abraham Lincoln was once asked how long a man's legs should be; his reply was "long enough to reach the ground". So too with complexity in large information systems. You need as much as you need. And you need more complexity as the system gets bigger. [Anyone who doubts that this is a general law should consider, for example, the anatomy of a single-celled organism versus your average mammal: the mammal has all sorts of specialized sub-systems - e.g. the circulatory system, which has its own specialized failure modes such as blockages caused by a variety of buildups - which the smaller - and simpler - organism lacks. (And no matter which side of the evolution/design split you fall on, you have to agree that something pretty intense decided it *really needed* that extra complexity! :-)] So the questions really are: - Do we need this extra complexity (and necessarily consequent new failure modes), and - If so, how do we deal with the problems this extra complexity brings, e.g. how to protect against those failure modes, how to make sure we can debug/fix failures (i.e. operations/maintainence issues), etc. If our goals are i) to not modify hosts, and ii) add another namespace - both goals which I think are reasonable - then *necessarily*, something out there is going to have to do mappings. So now the only question left is "how to deal with the problems this inventably brings, such as new failure modes". Now, that's a reasonably well-understood field. Systems designers have been dealing with these issues for many decades now. Some of the tools we use to do this are: - a) Make sure we don't have any dependency loops (i.e. subsystem A depends on subsystem B which depends on subsystem A) - b) Make sure our debugging tools for debugging system Y (which depends on X and below) only depend on X and below, and make sure we have direct access to X and below, without going through Y - c) In a distributed system, use replication to ensure availability These are tools we already use - e.g. when you type IP addresses directly into a tool, without using DNS, you're doing b); and DNS itself uses c) to increase its robustness. And there are more techniques, I won't go into a long spiel on them - the point is we know how to do this. And while I'm in this general area, I'd like to rant a bit about people who assume addresses, and routing (path-selection) mechanisms, are somehow fundamentally different - more reliable, more trustworthy, more available, more *special* - from every other mechanism (e.g. mapping services). They aren't. It kind of drives me batty when people assume raw IPvN-style addresses are somehow fundamentally different from all other possible mechanisms, that they have some ethereal quality which necessarily makes them more reliable, more dependable, than all other mechanisms. They aren't. Path-selection and forwarding are also complex distributed system with all sorts of failure modes. The people who designed them are fully aware of how critical they are, and have used a lot of ingenuity, and in many cases some pretty complex and heavy-weight mechanisms (try read the IS-IS or OSPF specs) to make sure they *are* reliable and dependable. But they accepted that complexity to make the *overall* operation one that one can rely on. So, circling back to where we started, given a certain goal-set (not modify hosts, and add another namespace) then something out there is going to have to do mappings; and we'll just have to deal with the problems this inventably brings: but I think we know how. > this brings up a fundamental point we need to consider in all cases of > locator/id split ... > ... reachability being predicated on a service ... one of the possible > negative side effects, of a locator/id split of any type. If you get to change the hosts, you can avoid this problem in a number of ways. One is to say that *all* DNS entries have to contain both location and identity names, and the lookup returns them both, and they travel around forever thereafter as a tuple (unless the binding is modified in some suitably-secure way). Another is to keep the existing DNS (returns location-name only), and pass identities in the connection-open packets in each direction. Etc, etc... Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 10:36: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 1HTfQA-0005KW-Q3; Tue, 20 Mar 2007 10:34:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTfQ9-0005I9-5g for ram@iab.org; Tue, 20 Mar 2007 10:34:41 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTfPt-0004iO-UC for ram@iab.org; Tue, 20 Mar 2007 10:34:41 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 20 Mar 2007 07:34:25 -0700 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 l2KEYPcv032000; Tue, 20 Mar 2007 07:34:25 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l2KEYLEi012225; Tue, 20 Mar 2007 14:34:21 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, 20 Mar 2007 07:34:20 -0700 Received: from [130.129.17.126] ([10.21.146.223]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 07:34:20 -0700 In-Reply-To: <45FFD2BA.7050601@cisco.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <45FFD2BA.7050601@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <004F88D9-FFC8-4EA2-96DD-A497EFCCC808@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] dns discover in map-and-encaps schemes Date: Tue, 20 Mar 2007 07:34:18 -0700 To: Russ White X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 14:34:20.0396 (UTC) FILETIME=[D8BDAAC0:01C76AFC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=852; t=1174401265; x=1175265265; 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]=20dns=20discover=20in=20map-and-encaps=20scheme s |Sender:=20; bh=4BCkgFvGcxaalGVew8L7WmiJS2cDVvx1kQqD9PmC/70=; b=PAT+DY0U4AeYIBldkJwelKv257Bp+qjEqRo4cUl1yWhs2zs51b2yAWmxrAs11X0HUb02R8ON JHWhrmzxJpNgAAMA2Hw3Po6Q9eAkfkR0zhZMPbVLme3bNHkj+YT/ppRe; 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: "Templin, Fred L" , rrg , 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 >> What happens when I type "ping " on the source? >> What if >> DNS is down, do I lose global connectivity? What if one of the two >> domain names don't exist in DNS? What if network administrators are >> totally against making routers DNS servers? What if your ITR is a >> low-end router where it can store both the DNS cache and mapping >> database? >> >> What I am trying to say is, some things need to go into the >> network and >> some things should just stay out of the network. > > Don't these same questions/issues apply to the LISP 1.5/2.0/etc > schemes > which follow LISP 1? Perhaps just replacing "DNS server" with > something > else? Exactly why I asked the questions. > In fact, won't these questions apply to any real locator/id split > system, in some form or another? Yep. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 10:45: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 1HTfZw-0002yD-KC; Tue, 20 Mar 2007 10:44:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTfZv-0002y7-1a for ram@iab.org; Tue, 20 Mar 2007 10:44:47 -0400 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTfZt-00078x-Ey for ram@iab.org; Tue, 20 Mar 2007 10:44:47 -0400 Received: from [130.129.16.84] (dhcp-1054.ietf68.org [130.129.16.84]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id l2KEifmt023678; Tue, 20 Mar 2007 07:44:42 -0700 (PDT) In-Reply-To: <317A019F-B8A4-4B89-AD87-0892548D7C6D@cisco.com> References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> <20070319034300.GA21041@vaf-lnx1.cisco.com> <18C09EFB-05BE-4170-9D16-8120A22311EB@cs.ucla.edu> <317A019F-B8A4-4B89-AD87-0892548D7C6D@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lixia Zhang Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Tue, 20 Mar 2007 07:44:39 -0700 To: Tony Li X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Daniel Massey , Yan Chen , 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 Mar 20, 2007, at 5:44 AM, Tony Li wrote: > > On Mar 20, 2007, at 1:05 PM, Lixia Zhang wrote: > >>> How big of a problem this is, I can't say. I don't know if >>> anyone has done any kind of analysis of the average number of >>> more specifics if someone does decide to de-aggregate. >> >> I wonder what Tony meant by "analysis of the average number of >> more specifics if someone does decide to de-aggregate"--do you >> mean if someone does decide to de-aggregate IPv6 prefix? > > > Lixia, > > Specifically what I'd like to see is for aggregates that have more > specifics present, what is the average number of those more > specifics per aggregate? > > Tony thanks for the clarification. The data Colorado State currently has (Yan Chen did it, I copied him on this reply) has all de-aggregation data sorted along various dimensions, should not be hard to dig out the number you asked. Lixia _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 11:24:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTgBb-0004AA-Rd; Tue, 20 Mar 2007 11:23:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTgBa-00046g-Ge for ram@iab.org; Tue, 20 Mar 2007 11:23:42 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTgBV-0004Po-NP for ram@iab.org; Tue, 20 Mar 2007 11:23:42 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 20 Mar 2007 08:23:37 -0700 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 l2KFNbef004678; Tue, 20 Mar 2007 08:23:37 -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 l2KFNbZT007182; Tue, 20 Mar 2007 15:23:37 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, 20 Mar 2007 08:23:37 -0700 Received: from [130.129.17.126] ([10.21.146.223]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 08:23:36 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747E0@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747E0@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24AFA5C0-D952-462C-B1D9-FAF782769F95@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] dns discover in map-and-encaps schemes Date: Tue, 20 Mar 2007 08:23:34 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 15:23:36.0597 (UTC) FILETIME=[BAC62450:01C76B03] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1509; t=1174404217; x=1175268217; 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]=20dns=20discover=20in=20map-and-encaps=20scheme s |Sender:=20; bh=4EPVw2ec3cADIo6IE25UXEMgzkXoAyR5TxrjzFDBa3w=; b=IRHOX5jx5Z0jnfoM8zmxNlObZ9gnTvDSJ2i2hL7EiASwa41goGNjjwOdSv87ABi33NlsCnsO Qxm/LcCoMu48uJyZFlqt+LuKfOOw0BLO2+uLreQZgloqIJpYf8JWLVR7; 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ram@iab.org, rrg 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 >> How do you get locators when the DNS is down? > > When the DNS is down, you will still be able to use IPv4 in the > same way we use IPv4 in the Internet today. The draft doesn't > explicity say this, but the preferred access method is IPv4, > with IPv6 used only for nodes that do not have a FQDN and IPv4 > addresses in the global DNS. IPvLX augments the current > architecture, it does not compromise it. You told me why it would work. I want to know how. You didn't answer my question. So if a host sends a DNS query to the router (you have said the router is a DNS server), and the router then needs to resolve egress.example.com and can't, please tell me what happens. You can't say just like IPv4 today because this doesn't happen in IPv4 today. > That still won't make network administrators happier. > Howso? Why should the network administrator care if the end > node is simply behaving as an ordinary DNS resolver from an > outward appearance. That the end node is behaving as a I didn't say they cared about that. They want to manage DNS servers in what has been traditionally known as "host systems", like one running FreeBSD, Linux, or Windows Server. > two-faced DNS server on behalf of its downstream-attached > devices (and internal virtual hosts) is no business of the > network administrator's. Right, give me a break. The network administrator manages this stuff and is responsible for making it work and keeping it working. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 11:32:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTgIm-0001mp-0K; Tue, 20 Mar 2007 11:31:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTgIl-0001mg-67 for ram@iab.org; Tue, 20 Mar 2007 11:31:07 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTgIj-0005hw-Sb for ram@iab.org; Tue, 20 Mar 2007 11:31:07 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 20 Mar 2007 08:31:05 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2KFV5aC019846; Tue, 20 Mar 2007 08:31:05 -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 l2KFV5AA028397; Tue, 20 Mar 2007 15:31:05 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, 20 Mar 2007 08:31:05 -0700 Received: from [130.129.17.126] ([10.21.146.223]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 08:31:04 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747E1@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com><031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747DB@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747E1@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EB48E26-7AF8-48CC-B981-76B9438CE5BE@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Date: Tue, 20 Mar 2007 08:31:03 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 15:31:04.0765 (UTC) FILETIME=[C5E726D0:01C76B04] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1575; t=1174404665; x=1175268665; 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[RRG]=20Initial=20comments=20on=20the=20LISP=20propos al |Sender:=20; bh=17wbDkNMbcjpNM+HGHtK9JZIsebc5uIjuWFWVinVmLY=; b=LhWjfchwL8mn+0Vn5R5hz+/lO+M5prVvv+N2noGB82HrLrZ6sg73QC3/Wi9GEtiCiPjOkRHr ZL45/N+h7xsUW9IXXd5y5XCtBxqGBWtGSLWPHMkBILRGG1KTrDhrLQVe; 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: rrg , ram@iab.org Subject: [RAM] Re: [RRG] Initial comments on the LISP proposal 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 depends on the implementation. I plan to not support it this >> way. LISP does not require the implementation to configure static >> tunnel interfaces in the ITRs and ETRs but strongly >> recommends it for >> TE-ITRs and TE-ETRs. > > I'm not concerned about the LISP-enlightened nodes; I'm concerned > for the legacy nodes that don't yet implement the scheme and I > believe you may be in for some backward-compatibility issues. The legacy nodes don't are not LISP boxes and don't have to change. To them the packets between the ITR and ETR are just plain old IPv4 or IPv6 packets. >>> 3) Sending encapsulated packets when there is no way of knowing >>> whether there is a suitably-configured decapsulator on the path >>> could fail to reach some services, e.g., services that reside >>> behind NAT boxes and have "holes" punched in the NAT that only >>> recognize unencapsulated packets. >> >> Same issue when you don't inject your site based route into BGP. > > I don't understand your response; I was saying that the encapsulated > packets are delivered to the NAT box in front of the server, but the > NAT has a hole punched through it that only recognizes unencapsulated > packets. The service will therefore be unreachable. NAT breaks a lot of things. The ETR has to be upstream of the NAT or collocated in the NAT. >> Yep, a problem with any tunneling design. > > Fixable with a suitable tunnel path MTU assurance mechanism. Yes, you can do PMTU with encapsulated data packets from ITR to ETR. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 12:05: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 1HTgnK-0008VG-9Z; Tue, 20 Mar 2007 12:02:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTgnJ-0008VA-R2 for ram@iab.org; Tue, 20 Mar 2007 12:02:41 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTgnF-0006VF-AC for ram@iab.org; Tue, 20 Mar 2007 12:02:41 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2KG2XV6001328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Mar 2007 09:02:34 -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 l2KG2Xrj013187; Tue, 20 Mar 2007 11:02:33 -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 l2KG2R2P012904; Tue, 20 Mar 2007 11:02:33 -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); Tue, 20 Mar 2007 09:02:32 -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] dns discover in map-and-encaps schemes Date: Tue, 20 Mar 2007 09:01:46 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017747EC@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <24AFA5C0-D952-462C-B1D9-FAF782769F95@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] dns discover in map-and-encaps schemes Thread-Index: AcdrA7wysOMk9vhmQ0a+ERxSxO3FPQAAl6wg References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747E0@XCH-NW-7V2.nw.nos.boeing.com> <24AFA5C0-D952-462C-B1D9-FAF782769F95@cisco.com> From: "Templin, Fred L" To: "Dino Farinacci" X-OriginalArrivalTime: 20 Mar 2007 16:02:32.0641 (UTC) FILETIME=[2B2A2B10:01C76B09] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 Dino, (Taking Lixia's guidance and reducing down to one list):=20 > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com]=20 > Sent: Tuesday, March 20, 2007 8:24 AM > To: Templin, Fred L > Cc: rrg; ram@iab.org > Subject: Re: [RAM] dns discover in map-and-encaps schemes >=20 > >> How do you get locators when the DNS is down? > > > > When the DNS is down, you will still be able to use IPv4 in the > > same way we use IPv4 in the Internet today. The draft doesn't > > explicity say this, but the preferred access method is IPv4, > > with IPv6 used only for nodes that do not have a FQDN and IPv4 > > addresses in the global DNS. IPvLX augments the current > > architecture, it does not compromise it. >=20 > You told me why it would work. I want to know how. You didn't answer =20 > my question. So if a host sends a DNS query to the router (you have =20 > said the router is a DNS server), and the router then needs to =20 > resolve egress.example.com and can't, please tell me what happens. OK, so going with what I said earlier about IPv4 being the preferred service, what I would like to see happen is for the router to first try to resolve "dest.example.com". If that resolves to a set of A records, then the router can simply return them to the end system and the application can use IPv4 - great! But, if there are no resource records for "dest.example.com", the router would then resolve "egress.example.com" and get back a set of A records for that. Then, it would send the Node Information Query for "dest.example.com" to one of those IPv4 addresses and get a set of AAAA records back. But, a nice optimization would be if the router could resolve "dest.example.com" and "egress.example.com" *both at the same time* and then act according to the algorithm above based on what it gets back. Maybe you know - is it possible to "batch" multiple queries in a single DNS transaction? As to failure to resolve either domain name, why would it be any different than for the same thing in today's Internet? The end system tries to resolve a FQDN and gets no resource records back. Maybe you are concerned that the router would appear to be "alive" from the end system's perspective while the global DNS service was "dead". In that case, why can't the server process on the router simply "play dead"? > You can't say just like IPv4 today because this doesn't happen in =20 > IPv4 today. >=20 > > That still won't make network administrators happier. >=20 > > Howso? Why should the network administrator care if the end > > node is simply behaving as an ordinary DNS resolver from an > > outward appearance. That the end node is behaving as a >=20 > I didn't say they cared about that. They want to manage DNS servers =20 > in what has been traditionally known as "host systems", like one =20 > running FreeBSD, Linux, or Windows Server. >=20 > > two-faced DNS server on behalf of its downstream-attached > > devices (and internal virtual hosts) is no business of the > > network administrator's. >=20 > Right, give me a break. The network administrator manages this stuff =20 > and is responsible for making it work and keeping it working. Hmm; I hear about end systems implementing personal firewalls these days. If they do that, then why can't they also implement personal DNS servers? Fred fred.l.templin@boeing.com > Dino >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 13:23: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 1HThzw-0001KS-Da; Tue, 20 Mar 2007 13:19:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HThzv-0001KM-9B for ram@iab.org; Tue, 20 Mar 2007 13:19:47 -0400 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HThzs-0007SU-Pr for ram@iab.org; Tue, 20 Mar 2007 13:19:47 -0400 Received: from [130.129.16.84] (dhcp-1054.ietf68.org [130.129.16.84]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id l2KHJdhU011177; Tue, 20 Mar 2007 10:19:40 -0700 (PDT) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017747E7@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A1017747C3@XCH-NW-7V2.nw.nos.boeing.com> <031C407A-78EF-440A-B40E-267237DBA7D6@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747D6@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1017747E0@XCH-NW-7V2.nw.nos.boeing.com> <66755836-34A1-4375-AE21-75164CE3147E@cs.ucla.edu> <39C363776A4E8C4A94691D2BD9D1C9A1017747E7@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5C8B6CC9-19A1-4045-A7F2-651447D02B0E@CS.UCLA.EDU> Content-Transfer-Encoding: 7bit From: Lixia Zhang Subject: Re: [RRG] RE: [RAM] dns discover in map-and-encaps schemes Date: Tue, 20 Mar 2007 10:19:38 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ram@iab.org, rrg 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 Mar 20, 2007, at 7:33 AM, Templin, Fred L wrote: > Hi Lixia, and thanks for the guidance on this. I certainly agree > with minimizing the clutter, and am happy to move to just one list. > I don't have a preference as to which one, so I defer to your > judgement and will use just one list from now on. > > But, a procedural question: how can we decide which is the > appropriate list on a case-per-case basis? (I think we still > have all three of the ram, rrg, and architecture-discuss lists > to choose from?) let me try a paraphrase of Leslie's answer when this question was raised at RRG meeting last Saturday (I copied Leslie here in case I say it wrong): RRG list should be used for messages related to RRG's efforts in developing a scalable routing&addressing architecture. RAM list should be used for messages related to Internet routing and addressing that are out of RRG scope. arch-d list should be used for all other architecture related issues. Lixia _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 14:46: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 1HTjJq-0000zP-Bd; Tue, 20 Mar 2007 14:44:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTjJo-0000vK-HN for ram@iab.org; Tue, 20 Mar 2007 14:44:24 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTjJi-0004zF-8Q for ram@iab.org; Tue, 20 Mar 2007 14:44:24 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 20 Mar 2007 11:44:18 -0700 X-IronPort-AV: i="4.14,305,1170662400"; d="scan'208"; a="693522442:sNHT48073564" Received: from rcallon-lt1.juniper.net ([172.23.1.96]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l2KIi8J92947; Tue, 20 Mar 2007 11:44:13 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070320142450.033b78f0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 20 Mar 2007 14:42:57 -0400 To: Leslie Daigle , ram@iab.org From: Ross Callon Subject: Re: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt In-Reply-To: <45FE8ED1.40900@thinkingcat.com> References: <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: iab@ietf.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 09:23 AM 3/19/2007 -0400, Leslie Daigle wrote: >Ross, everyone, > >As has been noted by a few folks already, the purpose >of this document is strictly and uniquely to document >the discussion that occurred at the workshop. > >Lixia has already provided pointers to some of the >disclaimer text in the document. > >The IAB is eager to publish the workshop report for >the very reason that discussion and thinking have >clearly moved on in the intervening months. It is >time to close the workshop chapter and focus on >the subsequent ones. I understand the desire to publish the report and be done with it. My concern has two closely related parts: One part is that the discussions that we had in Amsterdam are in some significant ways at odds with what I have since heard from multiple engineers from more than one company who are actually building the devices that the workshop was discussing. The second part of this is that the result of this discrepancy is that the report is more alarming than what I now believe is the reality (based on the best growth projections that I have seen as reported on this list, and based on what hardware engineers and software engineers tell me they are actually building with specific time lines for delivery). I am a little bit concerned that this might cause undue alarm among engineers reading the report. I am much more concerned about the admittedly less likely possibility that this might cause concern that shows up in the popular press. I don't want the New York Times to have a headline on their Sunday Technology page saying "the Internet is about to fail", regardless of whether this is true, but especially since I believe that it is not imminently true. This does not in any way reduce my interest in seeing people work on the problem and come up with better solutions (if better solutions exist that don't cause other problems), but it does mean that I want to be careful about any publication that appears important enough for the popular press to have some chance of picking it up. Ross >Comments that help clarify the text as a representation >of what was discussed at the event will be gratefully >accepted for the document. Everything else -- is >input to the current discussions (on RAM, RRG, >ROAP, etc). > >Thanks, >Leslie. > > > >Ross Callon wrote: >>At 10:03 PM 3/18/2007 -0700, Yakov Rekhter wrote: >>>... >>>I do not think Tony's suggestion is sufficient. The document >>>needs to clearly spell out the implications of using RLDRAM >>>instead of DRAM. Specifically, whether the document conclusions >>>still hold even if one uses RLDRAM. >>> >>>Yakov. >>To me it seems like our understanding of the problem, and of >>potential solutions, continues to evolve over time (particularly >>as we look into the details more closely). As one example, I >>personally was not aware of the distinction between RLDRAM >>and regular DRAM when in Amsterdam, nor was this difference >>discussed in Amsterdam, but I have learned about this since >>returning from the workshop. >>This leads to a question: To what extent is the workshop report >>supposed to be an accurate description of what went on at the >>workshop, and to what extent is it supposed to be an accurate >>description of what we *now* feel is the problem and range of >>possible solutions? I haven't sent in detailed comment on the >>report because I think that it is an accurate description of what >>was discussed at the time in Amsterdam, and also because I >>don't think that our understanding of the problem will become >>static for quite a while (so if the document needs to reflect >>current improved understanding, it won't be fully stable for quite >>a while). >>The document's abstract states: >> This document reports the outcome of the Routing and Addressing >> Workshop which the Internet Architecture Board (IAB) held on >> October 18-19, 2006 in Amsterdam, Netherlands. >> ... >> Note that this document is a report on the proceedings of the >> workshop. The views and positions documented in this report are >> those of the workshop participants and not the IAB. >>According to the first sentence of the abstract I would not expect >>the document to be an accurate description of the more detailed >>or more precise work that has gone on since the workshop, nor >>an accurate reflection of the greater level of understanding that has >>occurred since (which to me appears to still have a long way to go). >>In fact, the last sentence is not quite right, since the views and >>positions documented in the report are those that were stated by >>workshop participants at the time, and do not necessarily reflect >>the *current* views of at least some of the workshop participants. >>Perhaps we should add an additional sentence to either the >>abstract or to the last paragraph of section 1 that says: >> Work on issues related to this workshop report is continuing, >> and this document does not intend to accurately reflect the >> increased understanding of issues nor to discuss the range of >> potential solutions that may be the outcome of this ongoing work. >>Ross _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 17:33:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTlve-0007mw-2v; Tue, 20 Mar 2007 17:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTlvd-0007mr-F5 for ram@iab.org; Tue, 20 Mar 2007 17:31:37 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTlvb-0002H2-3p for ram@iab.org; Tue, 20 Mar 2007 17:31:37 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2007 22:31:31 +0100 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 l2KLVU0W020318; Tue, 20 Mar 2007 22:31:30 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2KLVClh017923; Tue, 20 Mar 2007 21:31:25 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 22:31:23 +0100 Received: from [10.0.1.235] ([10.61.64.154]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 22:31:22 +0100 In-Reply-To: References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> <20070319034300.GA21041@vaf-lnx1.cisco.com> <18C09EFB-05BE-4170-9D16-8120A22311EB@cs.ucla.edu> <317A019F-B8A4-4B89-AD87-0892548D7C6D@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <769C8A94-FDC7-4F9F-A0F9-647612EEF0AA@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Tue, 20 Mar 2007 22:31:19 +0100 To: Yan Chen X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 21:31:23.0000 (UTC) FILETIME=[1B600780:01C76B37] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=627; t=1174426290; x=1175290290; c=relaxed/simple; s=amsdkim2001; 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]=20Re=3A=20Impending=20publication=3A=20draft-ia b-raws-report-01.txt |Sender:=20; bh=LtH/izPFcWpAUxaZI12bUyTC6GDfT/jgHnqE4Zv9uzg=; b=dlCg6x0QZEOXVotMgmaoepOsdVOyYYh+z34fScfW/tVL3BVWUsAPyZDt4PmvlIaREYKFrR/M R78qHUE9lO07U6zEgXcGfhKCVHgJZEQzew3EAzTvtX9hkSnh9NVvC/2b; Authentication-Results: ams-dkim-2; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Daniel Massey , 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 Mar 20, 2007, at 9:55 PM, Yan Chen wrote: > Among 248,297 prefixes RV oreg 47 peers have seen during Jan 2007, > there are totally > 91,519 aggregates. 11,991 aggregates are covering some prefixes > (specifics), and on average each of them has about 13 specifics. And > an aggregate can have specifics up to 8,000. Thank you very much. So, then it's reasonable to assume that when a domain that is performing traffic engineering via more specifics converts to IPv6 that they will collapse the number of aggregates, but one aggregate will still be partitioned into multiple more specifics. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 17:33:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTlv2-0007bY-CZ; Tue, 20 Mar 2007 17:31:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTlv0-0007bT-NI for ram@iab.org; Tue, 20 Mar 2007 17:30:58 -0400 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTlur-0002Cr-1G for ram@iab.org; Tue, 20 Mar 2007 17:30:58 -0400 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id CAEEB53E0FC; Tue, 20 Mar 2007 16:30:39 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id YqnzRnjXD2Hs; Tue, 20 Mar 2007 16:30:29 -0500 (EST) Received: from [172.26.200.216] (ixe-nat1.juniper.net [193.110.54.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 14FAB53E0F8; Tue, 20 Mar 2007 16:30:28 -0500 (EST) In-Reply-To: References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <82CD83A7-9E72-4BFC-9D02-059A57408276@bgp.nu> Content-Transfer-Encoding: 7bit From: "John G. Scudder" Subject: Re: [RAM] what we should be working on Date: Tue, 20 Mar 2007 22:30:22 +0100 To: Chris L. Morrow X-Mailer: Apple Mail (2.752.3) 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 On Mar 20, 2007, at 11:17 AM, Chris L. Morrow wrote: > Does 1000bt (like in many/most 'new' computers 10/100/1000 copper) do > jumbo-frames already? I can't speak to the standardization status, but lots of consumer 1000bT gear supports jumbos. For example, all current Apple computers support jumbos, as do the dirt-cheap GE switches in my home. Not my DSL router, though (or I'd be awfully surprised if it did, anyway). --John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 17:42: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 1HTm59-0001NS-Nj; Tue, 20 Mar 2007 17:41:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTm58-0001NG-9u for ram@iab.org; Tue, 20 Mar 2007 17:41:26 -0400 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTm57-0003XA-28 for ram@iab.org; Tue, 20 Mar 2007 17:41:26 -0400 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 8FF3953E0FC; Tue, 20 Mar 2007 16:41:24 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id bKRUdS+nF3FJ; Tue, 20 Mar 2007 16:41:17 -0500 (EST) Received: from [172.26.200.216] (ixe-nat1.juniper.net [193.110.54.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 4709553E0F8; Tue, 20 Mar 2007 16:41:16 -0500 (EST) In-Reply-To: <769C8A94-FDC7-4F9F-A0F9-647612EEF0AA@cisco.com> References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> <20070319034300.GA21041@vaf-lnx1.cisco.com> <18C09EFB-05BE-4170-9D16-8120A22311EB@cs.ucla.edu> <317A019F-B8A4-4B89-AD87-0892548D7C6D@cisco.com> <769C8A94-FDC7-4F9F-A0F9-647612EEF0AA@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2BE88C31-A19B-4A74-A858-2A10061DA67E@bgp.nu> Content-Transfer-Encoding: 7bit From: "John G. Scudder" Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Tue, 20 Mar 2007 22:41:09 +0100 To: Tony Li X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Mar 20, 2007, at 10:31 PM, Tony Li wrote: > So, then it's reasonable to assume that when a domain that is > performing traffic engineering via more specifics converts to IPv6 > that they will collapse the number of aggregates, but one aggregate > will still be partitioned into multiple more specifics. That's roughly what I was trying to say (although I think I threw the word "site" in and muddied the water). The point being that instead of M prefixes each with a deaggregation factor of N, one might expect 1 prefix with a similar deaggregation factor. It's not a big deal, but does seem to indicate that the originally cited 74k prefixes might be an overcount. --John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 17:42: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 1HTm6H-0001c3-8V; Tue, 20 Mar 2007 17:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTlMu-0006wA-7r for ram@iab.org; Tue, 20 Mar 2007 16:55:44 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTlMs-0005g9-V3 for ram@iab.org; Tue, 20 Mar 2007 16:55:44 -0400 Received: by nf-out-0910.google.com with SMTP id y38so532179nfb for ; Tue, 20 Mar 2007 13:55:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=M8uVrWrPP51/dzOdiONmvwWvQmf/4Cu9ISdGcBQ+Ru7Q/qnq2vM20+P5yiye0GtCKImnuj0H6BSUdMjV+86VSpVkbyoJEm6wmbahEr00OStudBejS/1f06cGjHSv1T55hcg2alWlsh21bx9gdL3vIAjSZMfF486YrnHnkwawxgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=dMiTT2jxXcpMX52a8FUk5PA/qYDKU6ovSUpF2SPCgJGU9sciAn39xClodn1ZOGpKsXdmCSLAKTEebxKAiAagNtOFTPq0nkgiGM49B2YSxU0GHKRDfsVYN0zyjcWilzjKtYB0VKZH1om/NZb7mCZ1aNKwCxBsWsQppM8gB3bJokA= Received: by 10.82.175.2 with SMTP id x2mr10918bue.1174424141741; Tue, 20 Mar 2007 13:55:41 -0700 (PDT) Received: by 10.82.117.13 with HTTP; Tue, 20 Mar 2007 13:55:41 -0700 (PDT) Message-ID: Date: Tue, 20 Mar 2007 14:55:41 -0600 From: "Yan Chen" To: "Lixia Zhang" Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> <20070319034300.GA21041@vaf-lnx1.cisco.com> <18C09EFB-05BE-4170-9D16-8120A22311EB@cs.ucla.edu> <317A019F-B8A4-4B89-AD87-0892548D7C6D@cisco.com> X-Google-Sender-Auth: 09390d794b9c69ed X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Tue, 20 Mar 2007 17:42:36 -0400 Cc: Tony Li , Daniel Massey , 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, If I understand correctly, I think following is what you want. I assume that "aggregates" means prefixes without any other prefixes covering them. Among 248,297 prefixes RV oreg 47 peers have seen during Jan 2007, there are totally 91,519 aggregates. 11,991 aggregates are covering some prefixes (specifics), and on average each of them has about 13 specifics. And an aggregate can have specifics up to 8,000. If you want more detailed statistics, please let me know. Thanks Yan On 3/20/07, Lixia Zhang wrote: > > On Mar 20, 2007, at 5:44 AM, Tony Li wrote: > > > > > On Mar 20, 2007, at 1:05 PM, Lixia Zhang wrote: > > > >>> How big of a problem this is, I can't say. I don't know if > >>> anyone has done any kind of analysis of the average number of > >>> more specifics if someone does decide to de-aggregate. > >> > >> I wonder what Tony meant by "analysis of the average number of > >> more specifics if someone does decide to de-aggregate"--do you > >> mean if someone does decide to de-aggregate IPv6 prefix? > > > > > > Lixia, > > > > Specifically what I'd like to see is for aggregates that have more > > specifics present, what is the average number of those more > > specifics per aggregate? > >From ram-bounces@iab.org Tue Mar 20 17:42: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 1HTm59-0001NS-Nj; Tue, 20 Mar 2007 17:41:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTm58-0001NG-9u for ram@iab.org; Tue, 20 Mar 2007 17:41:26 -0400 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTm57-0003XA-28 for ram@iab.org; Tue, 20 Mar 2007 17:41:26 -0400 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 8FF3953E0FC; Tue, 20 Mar 2007 16:41:24 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id bKRUdS+nF3FJ; Tue, 20 Mar 2007 16:41:17 -0500 (EST) Received: from [172.26.200.216] (ixe-nat1.juniper.net [193.110.54.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 4709553E0F8; Tue, 20 Mar 2007 16:41:16 -0500 (EST) In-Reply-To: <769C8A94-FDC7-4F9F-A0F9-647612EEF0AA@cisco.com> References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> <20070319034300.GA21041@vaf-lnx1.cisco.com> <18C09EFB-05BE-4170-9D16-8120A22311EB@cs.ucla.edu> <317A019F-B8A4-4B89-AD87-0892548D7C6D@cisco.com> <769C8A94-FDC7-4F9F-A0F9-647612EEF0AA@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2BE88C31-A19B-4A74-A858-2A10061DA67E@bgp.nu> Content-Transfer-Encoding: 7bit From: "John G. Scudder" Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Tue, 20 Mar 2007 22:41:09 +0100 To: Tony Li X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Mar 20, 2007, at 10:31 PM, Tony Li wrote: > So, then it's reasonable to assume that when a domain that is > performing traffic engineering via more specifics converts to IPv6 > that they will collapse the number of aggregates, but one aggregate > will still be partitioned into multiple more specifics. That's roughly what I was trying to say (although I think I threw the word "site" in and muddied the water). The point being that instead of M prefixes each with a deaggregation factor of N, one might expect 1 prefix with a similar deaggregation factor. It's not a big deal, but does seem to indicate that the originally cited 74k prefixes might be an overcount. --John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 17:42: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 1HTm6H-0001c3-8V; Tue, 20 Mar 2007 17:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTlMu-0006wA-7r for ram@iab.org; Tue, 20 Mar 2007 16:55:44 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTl > > Tony > > thanks for the clarification. The data Colorado State currently has > (Yan Chen did it, I copied him on this reply) has all de-aggregation > data sorted along various dimensions, should not be hard to dig out > the number you asked. > > Lixia > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram Ms-0005g9-V3 for ram@iab.org; Tue, 20 Mar 2007 16:55:44 -0400 Received: by nf-out-0910.google.com with SMTP id y38so532179nfb for ; Tue, 20 Mar 2007 13:55:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=M8uVrWrPP51/dzOdiONmvwWvQmf/4Cu9ISdGcBQ+Ru7Q/qnq2vM20+P5yiye0GtCKImnuj0H6BSUdMjV+86VSpVkbyoJEm6wmbahEr00OStudBejS/1f06cGjHSv1T55hcg2alWlsh21bx9gdL3vIAjSZMfF486YrnHnkwawxgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=dMiTT2jxXcpMX52a8FUk5PA/qYDKU6ovSUpF2SPCgJGU9sciAn39xClodn1ZOGpKsXdmCSLAKTEebxKAiAagNtOFTPq0nkgiGM49B2YSxU0GHKRDfsVYN0zyjcWilzjKtYB0VKZH1om/NZb7mCZ1aNKwCxBsWsQppM8gB3bJokA= Received: by 10.82.175.2 with SMTP id x2mr10918bue.1174424141741; Tue, 20 Mar 2007 13:55:41 -0700 (PDT) Received: by 10.82.117.13 with HTTP; Tue, 20 Mar 2007 13:55:41 -0700 (PDT) Message-ID: Date: Tue, 20 Mar 2007 14:55:41 -0600 From: "Yan Chen" To: "Lixia Zhang" Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070318173916.7E05C872C9@mercury.lcs.mit.edu> <20070319034300.GA21041@vaf-lnx1.cisco.com> <18C09EFB-05BE-4170-9D16-8120A22311EB@cs.ucla.edu> <317A019F-B8A4-4B89-AD87-0892548D7C6D@cisco.com> X-Google-Sender-Auth: 09390d794b9c69ed X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Tue, 20 Mar 2007 17:42:36 -0400 Cc: Tony Li , Daniel Massey , 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, If I understand correctly, I think following is what you want. I assume that "aggregates" means prefixes without any other prefixes covering them. Among 248,297 prefixes RV oreg 47 peers have seen during Jan 2007, there are totally 91,519 aggregates. 11,991 aggregates are covering some prefixes (specifics), and on average each of them has about 13 specifics. And an aggregate can have specifics up to 8,000. If you want more detailed statistics, please let me know. Thanks Yan On 3/20/07, Lixia Zhang wrote: > > On Mar 20, 2007, at 5:44 AM, Tony Li wrote: > > > > > On Mar 20, 2007, at 1:05 PM, Lixia Zhang wrote: > > > >>> How big of a problem this is, I can't say. I don't know if > >>> anyone has done any kind of analysis of the average number of > >>> more specifics if someone does decide to de-aggregate. > >> > >> I wonder what Tony meant by "analysis of the average number of > >> more specifics if someone does decide to de-aggregate"--do you > >> mean if someone does decide to de-aggregate IPv6 prefix? > > > > > > Lixia, > > > > Specifically what I'd like to see is for aggregates that have more > > specifics present, what is the average number of those more > > specifics per aggregate? > > > > Tony > > thanks for the clarification. The data Colorado State currently has > (Yan Chen did it, I copied him on this reply) has all de-aggregation > data sorted along various dimensions, should not be hard to dig out > the number you asked. > > Lixia > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 18:08: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 1HTmUP-0004if-7e; Tue, 20 Mar 2007 18:07:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTmUO-0004iX-OI for ram@iab.org; Tue, 20 Mar 2007 18:07:32 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTmUN-0007Gx-DA for ram@iab.org; Tue, 20 Mar 2007 18:07:32 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 Mar 2007 23:07:31 +0100 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 l2KM7UOT027591; Tue, 20 Mar 2007 23:07:30 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2KM7QlZ025912; Tue, 20 Mar 2007 22:07:28 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 23:07:26 +0100 Received: from [10.0.1.235] ([10.61.64.154]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 23:07:25 +0100 In-Reply-To: <5.0.0.25.2.20070320142450.033b78f0@zircon.juniper.net> References: <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070320142450.033b78f0@zircon.juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Tue, 20 Mar 2007 23:07:23 +0100 To: Ross Callon X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Mar 2007 22:07:25.0872 (UTC) FILETIME=[248C1B00:01C76B3C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2038; t=1174428450; x=1175292450; c=relaxed/simple; s=amsdkim2001; 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=20Workshop=20report=20Re=3A=20[RAM]=20Re=3A=20Impending =20publication=3A=20draft-iab-raws-report-01.txt |Sender:=20; bh=EKNoLRCOxR0WAm6rtIxAFFo6qI4IBOOw5+uv+jMdT80=; b=AOAroycwiVMm7AwtZ6T9bSY1QjYN0f80pL8myKYPzRuLtvkb+ZBLB5JteR2JV3N0R4MdJqVM FdqBkQ0VqeMEQhhXJMLfcbYqg9DX348EXbHkhaKwp33eYJJrgQRfDidC; Authentication-Results: ams-dkim-2; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: iab@ietf.org, 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 Ross, > My concern has two closely related parts: One part is that the > discussions that we had in Amsterdam are in some significant > ways at odds with what I have since heard from multiple engineers > from more than one company who are actually building the devices > that the workshop was discussing. I assume that your concern is more specifically directed at my presentation and the subsequent discussion. Unfortunately, the engineers that you're talking to haven't had the decency to discuss their differences of opinion directly with me and present me with any hard factual data to the contrary. In fact, of all of the discussions that I've subsequently had, my concerns about DRAM and BGP convergence have only been reinforced. > The second part of this is that > the result of this discrepancy is that the report is more alarming > than what I now believe is the reality (based on the best growth > projections that I have seen as reported on this list, and based on > what hardware engineers and software engineers tell me they are > actually building with specific time lines for delivery). I'm having any trouble finding any conclusions in the report that are in any way alarming. Perhaps if you were a bit more specific, we could address any text that seems to be at issue. I stated in Amsterdam and have consistently maintained since that we do not have a short-term issue. > I am much more concerned about the admittedly less likely possibility > that this might cause concern that shows up in the popular press. I > don't want the New York Times to have a headline on their Sunday > Technology page saying "the Internet is about to fail", regardless of > whether this is true, but especially since I believe that it is not > imminently true. Nor is there anyone else that I know of that believes that it is true. Can you cite any language that seems to imply that there is a concern? Or could even be interpreted that way? Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 20 18:41:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTmyz-0002TS-QS; Tue, 20 Mar 2007 18:39:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTmyy-0002TN-Tq for ram@iab.org; Tue, 20 Mar 2007 18:39:08 -0400 Received: from pmesmtp02.wcom.com ([199.249.20.2] helo=pmesmtp02.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTmys-0002qE-8w for ram@iab.org; Tue, 20 Mar 2007 18:39:08 -0400 Received: from pmismtp02.mcilink.com ([166.37.158.162]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JF8005JZ48FV5@firewall.mci.com> for ram@iab.org; Tue, 20 Mar 2007 22:38:40 +0000 (GMT) Received: from pmismtp02.mcilink.com ([127.0.0.1]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JF800DET48FQZ@pmismtp02.mcilink.com> for ram@iab.org; Tue, 20 Mar 2007 22:38:39 +0000 (GMT) Received: from meno.corp.us.uu.net ([153.39.146.71]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JF800E0N48F55@pmismtp02.mcilink.com> for ram@iab.org; Tue, 20 Mar 2007 22:38:39 +0000 (GMT) Date: Tue, 20 Mar 2007 17:38:39 -0500 (EST) From: Jason Schiller Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt In-reply-to: <769C8A94-FDC7-4F9F-A0F9-647612EEF0AA@cisco.com> X-Sender: schiller@meno.corp.us.uu.net To: Tony Li Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: Yan Chen , ram@iab.org, Daniel Massey 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, 20 Mar 2007, Tony Li wrote: > On Mar 20, 2007, at 9:55 PM, Yan Chen wrote: > > > Among 248,297 prefixes RV oreg 47 peers have seen during Jan 2007, > > there are totally > > 91,519 aggregates. 11,991 aggregates are covering some prefixes > > (specifics), and on average each of them has about 13 specifics. And > > an aggregate can have specifics up to 8,000. > > > Thank you very much. > > So, then it's reasonable to assume that when a domain that is > performing traffic engineering via more specifics converts to IPv6 > that they will collapse the number of aggregates, but one aggregate > will still be partitioned into multiple more specifics. > > Tony So if you wanted to project how large the IPv6 Internet table would be tomorrow if everyone migrated to IPv6 you could do the following. Take the existing Internet table and break it into three types of routes: 1. "Aggrgeate" -- this is the first prefix assigned to the site. 2. "non-contiguous de-aggrgeate" -- when a site gets a second aggregate that is not contiguous to the first aggrgegate. (for example a site gets assigned 1.2.3.0/24 and the three years later needs more space and gets 2.3.4.0/22) 3. "intentional more specifics" -- when a site intentionally advertises a more specific of an aggregate (for example 2.3.4.0/22, 2.3.4.0/23, 2.3.6.0/23, and 2.3.7.0/24) As an example take an existing site that is advertising the following: 1.2.3.0/24 2.3.4.0/22 2.3.4.0/23 2.3.6.0/23 2.3.6.0/24 You have five prefixes that could be aggregated down to two CIDR prefixes. If you take the total number of prefixes (5) and subtract the number of CIDRs you could aggregate down to (2) you get the number of intentional more specifics for TE (3). If you take the number of intentional more specifics (3) and a single aggregate for each AS (in this case 1) you can calculate the project IPv6 routing table (4). If you do this for the Internet as a whole you might get something like the following: 2007-03-21 CIDR report: Date Prefixes CIDR aggrgegated 21-03-07 212772 137673 AS Sumary: 24579 Number of ASes in routing system 212772 - 137673 = 75099 "intentional more specifics" Add to that one aggregate for each active As in the routing system: 75099 + 24579 = 99678 routes in the IPv6 routing table if everyone did dual stack tomorrow and multi-homing in the same was as currently done of IPv4 ===================== ASSUMPTIONS: ok, so there are some assumptions here. 1. All "intentional more specifics" in the IPv4 are in the routing table for a reason, and not as an accident. If you think some of those prefixes in there are an accident, then the the number of routes in the IPv6 Internet table will be much worse as IPv6 provides much more roap to hang yourself with. (listen to my 65,536 /64s in my /48 as compaired to my 4 /24s in my /22 when I accidentally redistribute my routes into BGP) 2. This does not account for a single AS that has two non-contiguous assignments that would still advertise the same number of prefixes to the Internet routing table if it had a single contiguous assignment. (e.g. Company.com has 3.4.5.0/24 and 4.5.6.0/24. Both prefixes are orignated by AS1234. Compnay.com has an East coast HQ and a West coast HQ. These networks are not interconnected, but both get transit from the same two upstream ASes. Compnay.com trades 3.4.5.0/24 and 4.5.6.0/24 for 6.7.8.0/23. Since each location is a stub, it will still announce two prefixes 6.7.8.0/24 and 6.7.9.0/24.) 3. This does not account for all of the ASes that announce only a single /24 to the Internet routing table, but would announce more specifics if they were generally accepted. When all sites get a /48 then something more specific than a /48 will need to be permitted to allow fine grained TE. This means even small sites will be able to advertise more specifics to do fine grained TE. This might increase the average number of more specifics as compaired to the total number of aggregates. 4. This does not account for all of the networks that hide behind multiple NAT addresses from multiple providers who change the NAT address for TE. With IPv6 and the removal of NAT, they may need a different TE mechanism. That mechinism may be to advertise more specifics into the routing table. 5. The routing size is only projected form the current IPv4 routing table. This does not consider the potential new IPv6 networks, such as putting an IPv6 address on every cell phone, toaster, car, RFID, every household in China, etc... 6. It assumes wide spread adoption of IPv6 happening tomorrow... While that is unlikely, is it unlikly that it might happen by 2010? 2012? 2014? The point to this excersize is to figure out how big the routing table might be. If you look at historical trends for the number of ASes, the number of routes, and the number of intentional more specifics, you can project how big the routing table might be by 2010, 2012, 2014 if wide spread IPv6 adoption happens by then. You then need to examine your internal route growth and project the number of IPv6 internal routes you might have. From this you can project how long befor you are required to upgrade gear, and how long current state of the art gear will last in the network if you upgrade now. Lastly add in your normal equipment refresh cycle, life time you expect out of your equipment, and how many years you depreciate your equipment over. From this you can tell your vendors when you need new hardware, and how big it will need to be. So if you are on the verge of starting a new equipment refresh, and it takes you 2 years to fork-lift upgrade your network, and you depreciate your equipment for 5 years, and you think you need to ready for wide spread adoption of IPv6 by 2014, then you need to buy gear that will scale to the needs of the projected routing table size of 2014 (1,245,412 routes). And seven years from that repeat the process and look for gear that can scale to a projection of seven years out from then (2,386,401 routes). ___Jason > > _______________________________________________ > 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 Mar 20 18:48: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 1HTn6m-000551-FP; Tue, 20 Mar 2007 18:47:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTn6l-00054s-2F for ram@iab.org; Tue, 20 Mar 2007 18:47:11 -0400 Received: from web53004.mail.re2.yahoo.com ([206.190.49.34]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTn6j-0003ul-IX for ram@iab.org; Tue, 20 Mar 2007 18:47:11 -0400 Received: (qmail 81224 invoked by uid 60001); 20 Mar 2007 22:47:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XtzVl7NBu2ZXUdsQrMJSxplsWh9bZW23lT9ZM6cYYSHbNJFlapjFFNy0IxbosiHBTLFo6QGr2gmijpPiyh808xXjY6nRzj03TFOcVQTHChWGQKyjRQnvccqxMEt5CyBJ4ef3h3PAsZXZs98HOrRQb6Cu/36eo0qWLmNp/hq0m+s= ; Message-ID: <20070320224709.81221.qmail@web53004.mail.re2.yahoo.com> Received: from [128.200.132.173] by web53004.mail.re2.yahoo.com via HTTP; Tue, 20 Mar 2007 15:47:09 PDT X-Mailer: YahooMailRC/471 YahooMailWebService/0.6.132.8 Date: Tue, 20 Mar 2007 15:47:09 -0700 (PDT) From: Jessica Yu Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt To: "John G. Scudder" , Vince Fuller MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: iab@ietf.org, 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 the case John described below do exist. For example, my organizatio= n is currently advertising 3 /16's to the global routing table. It is not b= ecause of traffic engineering. It's because the prefixes just can not be ag= gregated due to pre-cidr allocation. In v6 world, one will be advertised.= =0A=0AI do not know how wide spread such situation exist. I would not be su= rprised that many organizations with pre-cidr address allocation would have= the same situation.=0A=0Acheers!=0A=0A--Jessica=0A=0A=0A----- Original Mes= sage ----=0AFrom: John G. Scudder =0ATo: Vince Fuller =0ACc: iab@ietf.org; ram@iab.org=0ASent: Monday, March 19, 2007 12:00= :23 PM=0ASubject: Re: [RAM] Re: Impending publication: draft-iab-raws-repor= t-01.txt=0A=0AOn Mar 18, 2007, at 11:43 PM, Vince Fuller wrote:=0A> 2) The = majority of more-specific prefixes in the global routing =0A> system are= =0A> advertised intentionally for traffic engineering or other =0A> pur= poses. In=0A> other words, relatively few more-specifics are configurati= on =0A> errors that=0A> would go away if only network operators were be= tter educated. =0A> One ipv6=0A> prefix would be needed for each of the= observed IPv4 more- =0A> specifics that=0A> are intentionally advertise= d today. This is 74K prefixes.=0A=0ASince some of the entities advertising = more-specifics have likely =0Aobtained multiple blocks of address space, f= rom which the more- =0Aspecifics are taken, then it would seem to follow th= at in the IPv6 =0Acase where we assume that each entity really just needs = a single =0Aaddress block, they'll advertise fewer more specifics. That i= s to =0Asay, there may be more than one more-specific per site now, becaus= e =0Aof the history of how address blocks were allocated, but in the IPv6 = =0Aworld one would hope for only a single more-specific per site.=0A=0ASo = 74k seems like an overcount, though I imagine not grossly so. =0A(I.e., I= wouldn't dispute it as a rough estimate, which I guess is =0Aall it purpo= rts to be.)=0A=0A--John=0A=0A______________________________________________= _=0ARAM mailing list=0ARAM@iab.org=0Ahttps://www1.ietf.org/mailman/listinfo= /ram=0A=0A=0A=0A=0A=0A =0A_________________________________________________= ___________________________________=0ASucker-punch spam with award-winning = protection. =0ATry the free Yahoo! Mail Beta.=0Ahttp://advision.webevents.y= ahoo.com/mailbeta/features_spam.html _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 21 01:06: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 1HTsx4-0002XP-BA; Wed, 21 Mar 2007 01:01:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTsx3-0002XE-5L for ram@iab.org; Wed, 21 Mar 2007 01:01:33 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTswy-0000Kd-DZ for ram@iab.org; Wed, 21 Mar 2007 01:01:31 -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 97D90154F2; Wed, 21 Mar 2007 06:01:21 +0100 (CET) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Mar 2007 05:55:29 +0100 To: Jason Schiller ,Tony Li From: JFC Morfin Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt In-Reply-To: References: <769C8A94-FDC7-4F9F-A0F9-647612EEF0AA@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070321050121.97D90154F2@smtp7-g19.free.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: Daniel Massey , Yan Chen , 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 am afraid that the reason why we users would convert to IPv6 is to have everyone benefit of an equal support, as it is the case with TV, radio, Fax, telephone today. Each individual (will soon have/has) serveral access through local line, wifi, powerlines, cable as a back-up or due to some servicing or local constraints or policies. I have three ISPs for my SoHo, including an IPv6 address. If multi-homing is permitted for one it must be permitted for all. I am attending a multi-candidate meeting tomorrow organised by ISOC France for the Presidential campaign. An IPv6 lobby have started a campaign for "everyone his/her permanent IP address". I am sure that main candidates will agree to pass a law establishing the PI concept as on the telephone (the French equivalent to the FCC has run a questionnaire 2 years ago where a permanent telephone number area was to be related to permanent IPv6 addresses). I think we really have to consider that whatever the way they are implemented PI will be for everyone. Moreover, that an ITU /3 block with a topographic numbering plan as discussed some time ago, would considerably reduce the international tables while permitting national PI to everyone. Managed in using the numbering plan I proposed, this would be built-in, whatever the ISP being used in parallel or not. jfc At 23:38 20/03/2007, Jason Schiller wrote: >On Tue, 20 Mar 2007, Tony Li wrote: > > > On Mar 20, 2007, at 9:55 PM, Yan Chen wrote: > > > > > Among 248,297 prefixes RV oreg 47 peers have seen during Jan 2007, > > > there are totally > > > 91,519 aggregates. 11,991 aggregates are covering some prefixes > > > (specifics), and on average each of them has about 13 specifics. And > > > an aggregate can have specifics up to 8,000. > > > > > > Thank you very much. > > > > So, then it's reasonable to assume that when a domain that is > > performing traffic engineering via more specifics converts to IPv6 > > that they will collapse the number of aggregates, but one aggregate > > will still be partitioned into multiple more specifics. > > > > Tony > >So if you wanted to project how large the IPv6 Internet table would be >tomorrow if everyone migrated to IPv6 you could do the following. > >Take the existing Internet table and break it into three types of routes: >1. "Aggrgeate" -- this is the first prefix assigned to the site. > >2. "non-contiguous de-aggrgeate" -- when a site gets a second aggregate >that is not contiguous to the first aggrgegate. (for example a site gets >assigned 1.2.3.0/24 and the three years later needs more space and gets >2.3.4.0/22) > >3. "intentional more specifics" -- when a site intentionally advertises >a more specific of an aggregate (for example 2.3.4.0/22, 2.3.4.0/23, >2.3.6.0/23, and 2.3.7.0/24) > >As an example take an existing site that is advertising the following: > >1.2.3.0/24 >2.3.4.0/22 >2.3.4.0/23 >2.3.6.0/23 >2.3.6.0/24 > >You have five prefixes that could be aggregated down to two CIDR prefixes. >If you take the total number of prefixes (5) and subtract the number of >CIDRs you could aggregate down to (2) you get the number of intentional >more specifics for TE (3). > >If you take the number of intentional more specifics (3) and a single >aggregate for each AS (in this case 1) you can calculate the project IPv6 >routing table (4). > >If you do this for the Internet as a whole you might get something like >the following: > >2007-03-21 CIDR report: >Date Prefixes CIDR aggrgegated >21-03-07 212772 137673 > >AS Sumary: >24579 Number of ASes in routing system > >212772 - 137673 = 75099 "intentional more specifics" > >Add to that one aggregate for each active As in the routing system: > >75099 + 24579 = 99678 routes in the IPv6 routing table if everyone did >dual stack tomorrow and multi-homing in the same was as currently done of >IPv4 > >===================== > >ASSUMPTIONS: > >ok, so there are some assumptions here. > >1. All "intentional more specifics" in the IPv4 are in the routing table >for a reason, and not as an accident. If you think some of those prefixes >in there are an accident, then the the number of routes in the IPv6 >Internet table will be much worse as IPv6 provides much more roap to hang >yourself with. (listen to my 65,536 /64s in my /48 as compaired >to my 4 /24s in my /22 when I accidentally redistribute my routes into >BGP) > >2. This does not account for a single AS that has two non-contiguous >assignments that would still advertise the same number of prefixes to the >Internet routing table if it had a single contiguous >assignment. (e.g. Company.com has 3.4.5.0/24 and 4.5.6.0/24. Both >prefixes are orignated by AS1234. Compnay.com has an East coast HQ and a >West coast HQ. These networks are not interconnected, but both get >transit from the same two upstream ASes. Compnay.com trades 3.4.5.0/24 >and 4.5.6.0/24 for 6.7.8.0/23. Since each location is a stub, it will >still announce two prefixes 6.7.8.0/24 and 6.7.9.0/24.) > >3. This does not account for all of the ASes that announce only a single >/24 to the Internet routing table, but would announce more specifics if >they were generally accepted. When all sites get a /48 then something >more specific than a /48 will need to be permitted to allow fine grained >TE. This means even small sites will be able to advertise more specifics >to do fine grained TE. This might increase the average number of more >specifics as compaired to the total number of aggregates. > >4. This does not account for all of the networks that hide behind multiple >NAT addresses from multiple providers who change the NAT address for >TE. With IPv6 and the removal of NAT, they may need a different TE >mechanism. That mechinism may be to advertise more specifics into the >routing table. > >5. The routing size is only projected form the current IPv4 routing >table. This does not consider the potential new IPv6 networks, such as >putting an IPv6 address on every cell phone, toaster, car, RFID, every >household in China, etc... > >6. It assumes wide spread adoption of IPv6 happening tomorrow... While >that is unlikely, is it unlikly that it might happen by 2010? 2012? 2014? > > >The point to this excersize is to figure out how big the routing table >might be. If you look at historical trends for the number of ASes, the >number of routes, and the number of intentional more specifics, you can >project how big the routing table might be by 2010, 2012, 2014 if wide >spread IPv6 adoption happens by then. > >You then need to examine your internal route growth and project the number >of IPv6 internal routes you might have. From this you can project how >long befor you are required to upgrade gear, and how long current state of >the art gear will last in the network if you upgrade now. > >Lastly add in your normal equipment refresh cycle, life time you expect >out of your equipment, and how many years you depreciate your equipment >over. From this you can tell your vendors when you need new hardware, and >how big it will need to be. > >So if you are on the verge of starting a new equipment refresh, and it >takes you 2 years to fork-lift upgrade your network, and you depreciate >your equipment for 5 years, and you think you need to ready for wide >spread adoption of IPv6 by 2014, then you need to buy gear that will scale >to the needs of the projected routing table size of 2014 (1,245,412 >routes). And seven years from that repeat the process and look for gear >that can scale to a projection of seven years out from then (2,386,401 >routes). > >___Jason > > > > _______________________________________________ > > 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 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 21 05:30: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 1HTx8M-0001w2-5e; Wed, 21 Mar 2007 05:29:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTx8I-0001sH-Bg for ram@iab.org; Wed, 21 Mar 2007 05:29:26 -0400 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTx7B-00037g-5L for ram@iab.org; Wed, 21 Mar 2007 05:28:18 -0400 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 3C50653E0F8; Wed, 21 Mar 2007 04:28:08 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id nJsxTcCMclW8; Wed, 21 Mar 2007 04:28:02 -0500 (EST) Received: from [172.26.200.216] (ixe-nat1.juniper.net [193.110.54.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 067D153E0EA; Wed, 21 Mar 2007 04:28:01 -0500 (EST) In-Reply-To: <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@cisco.com> References: <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070320142450.033b78f0@zircon.juniper.net> <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@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: "John G. Scudder" Subject: Re: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Wed, 21 Mar 2007 10:27:58 +0100 To: Tony Li X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: iab@ietf.org, 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, On Mar 20, 2007, at 11:07 PM, Tony Li wrote: > I assume that your concern is more specifically directed at my > presentation and the subsequent discussion. Unfortunately, the > engineers that you're talking to haven't had the decency to discuss > their differences of opinion directly with me and present me with > any hard factual data to the contrary. In fact, of all of the > discussions that I've subsequently had, my concerns about DRAM and > BGP convergence have only been reinforced. I take it you're referring specifically to section 4.1.1? In re- reading that I notice there's a factual error: In processing a BGP update, a BGP speaker receives a path and must compare it to all of the other paths it has stored for the prefix. That's how a naive implementation might do it, but a decent implementation typically won't. As I'm sure you know (but other readers of the report may not) there are various optimizations that can be done, which fall into at least two major categories. One is to use of previous knowledge about the state of a given route from a given peer (if a peer re-advertises a route to me which was not previously best, and the only change to that route was that e.g. LocalPref got worse, then I know without any further comparisons that it will not become best -- when applicable this type of optimization can make processing of a given update O(1)). The other is to make use of ordering over routes (basically, you can insertion sort routes for a given prefix, modulo MED). Granted that in the end, selection is still O(n) in the number of paths for a given prefix, but the statement as quoted is not quite right. As a meta-point, I think this demonstrates that back-of-envelope analysis of this particular issue -- even in the small -- is not straightforward and that intuition is not necessarily to be trusted. (At the risk of spinning us off on a tangent, I think it's also important to consider the behavior of the control plane as a system when under load -- not just the behavior of a single CPU. It's my contention that the behavior that emerges from the system when loaded is not as dire as one might be led to believe by examining just a single CPU's behavior and noticing that "the streams cross". I hope to say a few words about this at tomorrows routing area meeting.) Regarding your overall point above ("concerns about DRAM and BGP convergence") as relates to the workshop report, it's easy for the reader to completely miss it. The workshop report (and specifically, section 4) dwells at length on the FIB and the claim that Since high end routing is based on low volume technology, the cost advantages that the bulk of the broader computing industry sees based on Moore's law are not directly inherited. While the discussion of DRAM speed and access patterns as relates to BGP is potentially interesting, it's limited to five sentences in a single subsection of the report, not called out in the summary (of section 4, or of the overall document). For this reason, or perhaps because the readers are just dense (always a possibility) the message actually conveyed by the report is primarily about the FIB and the DRAM-vs-BGP conversation hasn't risen above the background noise level. In that context, I think Ross's comments make good sense. --John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 21 06:01: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 1HTxc5-00067Y-W1; Wed, 21 Mar 2007 06:00:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxc4-00067N-IN for ram@iab.org; Wed, 21 Mar 2007 06:00:12 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTxc1-0004th-9D for ram@iab.org; Wed, 21 Mar 2007 06:00:12 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2007 11:00:09 +0100 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 l2LA080w014755; Wed, 21 Mar 2007 11:00:08 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2LA03lb020211; Wed, 21 Mar 2007 10:00:08 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 11:00:05 +0100 Received: from [10.0.1.235] ([10.61.80.29]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 11:00:04 +0100 In-Reply-To: References: <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070320142450.033b78f0@zircon.juniper.net> <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <437F54B1-49AA-41BA-A81E-C76266AD19E7@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Wed, 21 Mar 2007 11:00:01 +0100 To: "John G. Scudder" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Mar 2007 10:00:04.0865 (UTC) FILETIME=[B2E4A710:01C76B9F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3910; t=1174471208; x=1175335208; c=relaxed/simple; s=amsdkim2001; 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=20Workshop=20report=20Re=3A=20[RAM]=20Re=3A=20Impending =20publication=3A=20draft-iab-raws-report-01.txt |Sender:=20; bh=eqVd1H0YJIBJqA1KdNCtxCnryHNzRITuOD33AzMqgTo=; b=Uett2r1b2KXZ1v+J1mRvTuKgMY5BPY5u7EDT4RuV66QuqsBWES81xRtER0S2jmvxTQetG4Wq 9pz3bKfDsibz9JR8gNg0Deph5JY2A3WhiMGR7njiXeP6ePFdUv9VrTdg; Authentication-Results: ams-dkim-2; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: iab@ietf.org, 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 John, > I take it you're referring specifically to section 4.1.1? In re- > reading that I notice there's a factual error: > > In processing a > BGP update, a BGP speaker receives a path and must compare it to > all > of the other paths it has stored for the prefix. > > That's how a naive implementation might do it, but a decent > implementation typically won't. As I'm sure you know (but other > readers of the report may not) there are various optimizations that > can be done, which fall into at least two major categories. One is > to use of previous knowledge about the state of a given route from > a given peer (if a peer re-advertises a route to me which was not > previously best, and the only change to that route was that e.g. > LocalPref got worse, then I know without any further comparisons > that it will not become best -- when applicable this type of > optimization can make processing of a given update O(1)). The > other is to make use of ordering over routes (basically, you can > insertion sort routes for a given prefix, modulo MED). Granted > that in the end, selection is still O(n) in the number of paths for > a given prefix, but the statement as quoted is not quite right. As > a meta-point, I think this demonstrates that back-of-envelope > analysis of this particular issue -- even in the small -- is not > straightforward and that intuition is not necessarily to be trusted. I'm not sure I'd call it a factual error, it's more of a generalization. You're still performing the function of a comparison, you're just listing some of the ways in which you can optimize the comparison. I wasn't getting into that level of detail because frankly, as it wasn't relevant to the argument. Whatever the complexity of doing best path evaluation, it's still multiplied by the number of prefixes. The access pattern is still unfortunately random, so convergence time is still going to be dominated by DRAM latency. > (At the risk of spinning us off on a tangent, I think it's also > important to consider the behavior of the control plane as a system > when under load -- not just the behavior of a single CPU. It's my > contention that the behavior that emerges from the system when > loaded is not as dire as one might be led to believe by examining > just a single CPU's behavior and noticing that "the streams > cross". I hope to say a few words about this at tomorrows routing > area meeting.) No one was claiming 'dire'. > Regarding your overall point above ("concerns about DRAM and BGP > convergence") as relates to the workshop report, it's easy for the > reader to completely miss it. Agreed. Unfortunately, as resources are finite, there's only so much that one can say. > The workshop report (and specifically, section 4) dwells at length > on the FIB and the claim that > > Since high end > routing is based on low volume technology, the cost advantages that > the bulk of the broader computing industry sees based on Moore's > law > are not directly inherited. > > While the discussion of DRAM speed and access patterns as relates > to BGP is potentially interesting, it's limited to five sentences > in a single subsection of the report, not called out in the summary > (of section 4, or of the overall document). For this reason, or > perhaps because the readers are just dense (always a possibility) > the message actually conveyed by the report is primarily about the > FIB and the DRAM-vs-BGP conversation hasn't risen above the > background noise level. > > In that context, I think Ross's comments make good sense. Perhaps I'm being dense, but I'm still failing to see how any of that language could possibly induce panic. Regards, Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 21 06:06: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 1HTxhp-0001lw-Mh; Wed, 21 Mar 2007 06:06:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxho-0001li-Em for ram@iab.org; Wed, 21 Mar 2007 06:06:08 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTxhj-000671-CN for ram@iab.org; Wed, 21 Mar 2007 06:06:08 -0400 Received: from [10.0.1.24] ([::ffff:64.103.37.2]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 21 Mar 2007 06:01:38 -0400 id 0158810F.46010283.0000202D Message-ID: <4601037D.2010907@thinkingcat.com> Date: Wed, 21 Mar 2007 06:05:49 -0400 From: Leslie Daigle User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Ross Callon Subject: Re: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt References: <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070320142450.033b78f0@zircon.juniper.net> <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@cisco.com> In-Reply-To: <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Tony Li , iab@ietf.org, 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 Ross, And I'm sympathetic to the desire not to make the discussion harder by text in the workshop report. But, this is fear, uncertainty & doubt; to echo one of Tony's points below, if you have specific concerns/suggestions: send text! Leslie. Tony Li wrote: > > Ross, > > >> My concern has two closely related parts: One part is that the >> discussions that we had in Amsterdam are in some significant >> ways at odds with what I have since heard from multiple engineers >> from more than one company who are actually building the devices >> that the workshop was discussing. > > > I assume that your concern is more specifically directed at my > presentation and the subsequent discussion. Unfortunately, the > engineers that you're talking to haven't had the decency to discuss > their differences of opinion directly with me and present me with any > hard factual data to the contrary. In fact, of all of the discussions > that I've subsequently had, my concerns about DRAM and BGP convergence > have only been reinforced. > > >> The second part of this is that >> the result of this discrepancy is that the report is more alarming >> than what I now believe is the reality (based on the best growth >> projections that I have seen as reported on this list, and based on >> what hardware engineers and software engineers tell me they are >> actually building with specific time lines for delivery). > > > I'm having any trouble finding any conclusions in the report that are in > any way alarming. Perhaps if you were a bit more specific, we could > address any text that seems to be at issue. I stated in Amsterdam and > have consistently maintained since that we do not have a short-term issue. > > >> I am much more concerned about the admittedly less likely possibility >> that this might cause concern that shows up in the popular press. I >> don't want the New York Times to have a headline on their Sunday >> Technology page saying "the Internet is about to fail", regardless of >> whether this is true, but especially since I believe that it is not >> imminently true. > > > Nor is there anyone else that I know of that believes that it is true. > Can you cite any language that seems to imply that there is a concern? > Or could even be interpreted that way? > > Tony > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 21 06:48: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 1HTyJf-0000yW-Hy; Wed, 21 Mar 2007 06:45:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTyJd-0000xd-VA for ram@iab.org; Wed, 21 Mar 2007 06:45:13 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTyJa-0001is-Bs for ram@iab.org; Wed, 21 Mar 2007 06:45:13 -0400 Received: from [IPv6:2001:df8::16:20a:95ff:fef5:246e] ([IPv6:2001:df8:0:16:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2LAiJIo042773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Mar 2007 11:44:20 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Wed, 21 Mar 2007 11:44:43 +0100 To: Jason Schiller X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 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.4 (--) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Tony Li , Daniel Massey , Yan Chen , 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 20-mrt-2007, at 23:38, Jason Schiller wrote: > So if you wanted to project how large the IPv6 Internet table would be > tomorrow if everyone migrated to IPv6 you could do the following. [...] > 3. This does not account for all of the ASes that announce only a > single > /24 to the Internet routing table, but would announce more > specifics if > they were generally accepted. When all sites get a /48 then something > more specific than a /48 will need to be permitted I'm sure a lot of people will feel that they need this, but I'm equally sure a lot of people will feel that they need to avoid prefixes longer than a /48 in their view of the global routing table. The question that remains unanswered here is the maximum prefix length that will be generally accepted throughout the network. For IPv4, that's a /24. If you announce anything longer than that, your chances of seeing that announcement appear in many remote places aren't good. Currently, if you go to: http://www.apnic.net/db/min-alloc.html http://lacnic.net/en/registro/index.html https://www.ripe.net/ripe/docs/ripe-ncc-managed-address- space.html#special_purpose_ranges http://www.arin.net/reference/micro_allocations.html you can see that /48s are given out from the following IPv6 ranges: 2001:0C00:/23 2001:1200::/23 001:0500::/30 and /35 from: 2001:0200:/23 (There is some additional internet exchange stuff but that shouldn't be in the global table anyway.) Apart from the above, the minimum allocation size is always /32. So it's extremely easy for operators to build filters that disallow any more specifics beyond /48 in the above ranges and beyond /32 for anything else. For IPv4, this is much more difficult and there are a lot of special cases that such a filter wouldn't catch. This means, that operators who care to do so, can easily filter on RIR boundaries in IPv6 so only holders of a prefix shorter than /32 get to deaggregate. I guess this means that the deaggregators will counter by simply requesting more prefixes, but I don't see that approach succeeding in the long run. My conclusion is that the IPv4 rules just don't apply to the IPv6 space and the best estimate for the IPv6 global table size is the number of active ASes adjusted by a small factor for < /32 deaggregation and mergers. However, now that the PI cat is out of the bag it's very possible that the number of ASes with a PI block will grow faster in IPv6 than what we've seen in IPv4. > The point to this excersize is to figure out how big the routing table > might be. If you look at historical trends for the number of ASes, > the > number of routes, and the number of intentional more specifics, you > can > project how big the routing table might be by 2010, 2012, 2014 if wide > spread IPv6 adoption happens by then. Don't count on wide scale IPv6 adoption before we effectively run out of IPv4 space. For anyone who has their IPv4 space today and doesn't need any extra, the incentive to move to IPv6 is minimal, and this won't change even after the IPv4 depletion. Since everyone else is still on v4, new internet users will need to connect to the existing v4 world in one way or another, which probably means heavy NAT, meaning very many users per IPv4 address. This is much more inconvenient than today's light NAT where, generally, only a small number of devices shares an IPv4 address and the end-user can control port mappings. For those new users, it makes sense to adopt IPv6 in addition to NATed IPv4 so they can communicate amongst themselves. Only after this has taken off, it becomes interesting for regular IPv4 users to also adopt v6 to connect to the NAT-hampered users. (Don't forget that for people who need a /24 or such, there will always be enough IPv4 space. It's the Comcasts and * Telecoms of this world that burn through millions of addresses per year that will hit the brick wall once they've consumed the remaining 1249 million IPv4 addresses.) The problem with all of this is that we probably can't make reasonable projections 7 years in advance so starting an upgrade cycle today for stuff that has to last for 7 years is problematic. Then again, we're only at the beginning of the video over IP revolution and 10 Gbit ethernet is getting long in the tooth so there are other reasons why I don't see today's gear being deployed in the core in the year 2014. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 21 07:58: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 1HTzPS-0006vi-DL; Wed, 21 Mar 2007 07:55:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzPQ-0006tH-LR for ram@iab.org; Wed, 21 Mar 2007 07:55:16 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTzP9-0007QS-GX for ram@iab.org; Wed, 21 Mar 2007 07:55:16 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 21 Mar 2007 04:54:59 -0700 X-IronPort-AV: i="4.14,308,1170662400"; d="scan'208"; a="693945117:sNHT33610216" Received: from rcallon-lt1.juniper.net ([172.23.1.96]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l2LBsXJ05671; Wed, 21 Mar 2007 04:54:45 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070321074437.033e1520@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 21 Mar 2007 07:54:25 -0400 To: Leslie Daigle , ram@iab.org From: Ross Callon Subject: Re: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt In-Reply-To: <4601037D.2010907@thinkingcat.com> References: <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@cisco.com> <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070320142450.033b78f0@zircon.juniper.net> <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Tony Li , iab@ietf.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 06:05 AM 3/21/2007 -0400, Leslie Daigle wrote: >...to echo >one of Tony's points below, if you have specific >concerns/suggestions: send text! a very reasonable request. Rereading the report yet again, I think that it is quite well written. It is somewhat of an art form to predict what external reaction might or might not occur to any given report. However, I think that it would probably be a good idea to add to the end of the abstract the sentence: Work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. Ross _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 21 08:09: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 1HTzd1-0007ux-6i; Wed, 21 Mar 2007 08:09:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzd0-0007up-L0 for ram@iab.org; Wed, 21 Mar 2007 08:09:18 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTzcy-00025x-0w for ram@iab.org; Wed, 21 Mar 2007 08:09:18 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2007 13:09:16 +0100 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 l2LC9F14026789; Wed, 21 Mar 2007 13:09:15 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2LC9ClZ004463; Wed, 21 Mar 2007 12:09:15 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 13:09:12 +0100 Received: from [130.129.18.65] ([10.61.81.20]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 13:09:12 +0100 In-Reply-To: <5.0.0.25.2.20070321074437.033e1520@zircon.juniper.net> References: <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@cisco.com> <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070320142450.033b78f0@zircon.juniper.net> <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@cisco.com> <5.0.0.25.2.20070321074437.033e1520@zircon.juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1AA4E5D8-6D27-4647-BE3A-3D2A54CAB80C@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt Date: Wed, 21 Mar 2007 13:09:04 +0100 To: Ross Callon X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Mar 2007 12:09:12.0363 (UTC) FILETIME=[BCC307B0:01C76BB1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=615; t=1174478955; x=1175342955; c=relaxed/simple; s=amsdkim2001; 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=20Workshop=20report=20Re=3A=20[RAM]=20Re=3A=20Impending =20publication=3A=20draft-iab-raws-report-01.txt |Sender:=20; bh=VKGNvh6MAwFat2IaVWm62/bK7Bu+PIHIMaYhzZcdkCs=; b=Mbt3VxoMvXAyNW2R0kXCCsiB3wxvpp3F4yWU2aZEPR/VWzw1whBISXxyvx9cyU/XaRHGax49 NK4Mm2zI+qt+TVI3UDH8xXLRr9clfiqNQpw2Gl6Wjp+9cgH/jchmeeFw; Authentication-Results: ams-dkim-2; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: iab@ietf.org, 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 > > Rereading the report yet again, I think that it is quite well > written. It is somewhat of an art form to predict what external > reaction might or might not occur to any given report. However, > I think that it would probably be a good idea to add to the end > of the abstract the sentence: > > Work on issues related to this workshop report is continuing, > and this document does not intend to reflect the increased > understanding of issues nor to discuss the range of potential > solutions that may be the outcome of this ongoing work. I can support that. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 21 08:34: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 1HTzzt-0005ln-GC; Wed, 21 Mar 2007 08:32:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzzr-0005k4-W3 for ram@iab.org; Wed, 21 Mar 2007 08:32:55 -0400 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTzzj-0008Rc-Hc for ram@iab.org; Wed, 21 Mar 2007 08:32:55 -0400 Received: from dhcp-10d8.ietf68.org ([130.129.16.216]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1HTzzZ-0001ZW-0V; Wed, 21 Mar 2007 13:32:39 +0100 Message-ID: <460125E2.4070708@pi.se> Date: Wed, 21 Mar 2007 13:32:34 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Tony Li Subject: Re: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt References: <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@cisco.com> <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070320142450.033b78f0@zircon.juniper.net> <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@cisco.com> <5.0.0.25.2.20070321074437.033e1520@zircon.juniper.net> <1AA4E5D8-6D27-4647-BE3A-3D2A54CAB80C@cisco.com> In-Reply-To: <1AA4E5D8-6D27-4647-BE3A-3D2A54CAB80C@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: iab@ietf.org, 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 wrote: > >> >> Rereading the report yet again, I think that it is quite well >> written. It is somewhat of an art form to predict what external >> reaction might or might not occur to any given report. However, >> I think that it would probably be a good idea to add to the end >> of the abstract the sentence: >> >> Work on issues related to this workshop report is continuing, >> and this document does not intend to reflect the increased >> understanding of issues nor to discuss the range of potential >> solutions that may be the outcome of this ongoing work. > > > I can support that. sure it won't do any harm, the only problem is that it refers to a discussion totally outside the report... /Loa > > Tony > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 21 14:55: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 1HU5vz-0007Yp-Hd; Wed, 21 Mar 2007 14:53:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU5vw-0007Wl-56; Wed, 21 Mar 2007 14:53:16 -0400 Received: from geoff.telstra.net ([203.50.0.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HU5vu-0005a9-Ev; Wed, 21 Mar 2007 14:53:16 -0400 Received: from vaioz1.apnic.net (dhcp13.potaroo.net [203.10.60.13]) by geoff.telstra.net (8.13.6/8.13.6) with ESMTP id l2LIqadJ022449; Thu, 22 Mar 2007 05:52:36 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20070322055032.041667d0@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 22 Mar 2007 05:50:55 +1100 To: Tony Li , Ross Callon From: Geoff Huston Subject: Re: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt In-Reply-To: <1AA4E5D8-6D27-4647-BE3A-3D2A54CAB80C@cisco.com> References: <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@cisco.com> <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070320142450.033b78f0@zircon.juniper.net> <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@cisco.com> <5.0.0.25.2.20070321074437.033e1520@zircon.juniper.net> <1AA4E5D8-6D27-4647-BE3A-3D2A54CAB80C@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: iab@ietf.org, 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:09 PM 21/03/2007, Tony Li wrote: >>Rereading the report yet again, I think that it is quite well >>written. It is somewhat of an art form to predict what external >>reaction might or might not occur to any given report. However, >>I think that it would probably be a good idea to add to the end >>of the abstract the sentence: >> >> Work on issues related to this workshop report is continuing, >> and this document does not intend to reflect the increased >> understanding of issues nor to discuss the range of potential >> solutions that may be the outcome of this ongoing work. > > >I can support that. ditto Geoff _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 05:43: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 1HUJnB-0004QX-Qh; Thu, 22 Mar 2007 05:41:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJnA-0004NX-IT for ram@iab.org; Thu, 22 Mar 2007 05:41:08 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJn6-0005Pa-8A for ram@iab.org; Thu, 22 Mar 2007 05:41:08 -0400 Received: from pmismtp04.wcomnet.com ([166.37.158.164]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JFA00MH9TKCTP@firewall.mci.com> for ram@iab.org; Thu, 22 Mar 2007 09:41:01 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([127.0.0.1]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JFA00CEGTKCV6@pmismtp04.mcilink.com> for ram@iab.org; Thu, 22 Mar 2007 09:41:00 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JFA00BB5TKCPR@pmismtp04.mcilink.com> for ram@iab.org; Thu, 22 Mar 2007 09:41:00 +0000 (GMT) Date: Thu, 22 Mar 2007 09:41:00 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: Workshop report Re: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt In-reply-to: <437F54B1-49AA-41BA-A81E-C76266AD19E7@cisco.com> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Tony Li Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070319080904.0364fa60@zircon.juniper.net> <5.0.0.25.2.20070320142450.033b78f0@zircon.juniper.net> <92D48FA3-6FC2-4FBF-83DC-41E5320787FD@cisco.com> <437F54B1-49AA-41BA-A81E-C76266AD19E7@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: iab@ietf.org, 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, 21 Mar 2007, Tony Li wrote: > No one was claiming 'dire'. > just to clarify, what is 'dire'? (not asking tony specifically more of a survey question) is 2 years 'dire'? 5 years? 10 years? When looking at design/build/purchase/test/deploy/depreciate timeframes of +7 years things get 'interesting' quickly. thanks -Chris _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 05:56: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 1HUK1J-0007Pv-PL; Thu, 22 Mar 2007 05:55:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUK1H-0007Ox-Vj for ram@iab.org; Thu, 22 Mar 2007 05:55:43 -0400 Received: from mail02.frontiercorp.com ([66.133.172.20] helo=frontiercorp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUK1G-0001c8-MY for ram@iab.org; Thu, 22 Mar 2007 05:55:43 -0400 Received: from ([10.160.67.162]) by mail02.frontiercorp.com with ESMTP id KP-AXMBT.140335066; Thu, 22 Mar 2007 05:59:24 -0400 Received: from nyrofcs2ke2k01.corp.pvt ([10.160.64.140]) by NYROFCS2KE2K05.corp.pvt with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Mar 2007 05:55:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Workshop report Re: [RAM] Re: Impending publication:draft-iab-raws-report-01.txt Date: Thu, 22 Mar 2007 05:55:34 -0400 Message-ID: <454810F09B5AA04E9D78D13A5C39028A01A3DDEB@nyrofcs2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Workshop report Re: [RAM] Re: Impending publication:draft-iab-raws-report-01.txt Thread-Index: AcdsZoGx/wz89t6WT0amhKTmBiRxnAAANHig From: "Azinger, Marla" To: "Chris L. Morrow" , "Tony Li" X-OriginalArrivalTime: 22 Mar 2007 09:55:35.0300 (UTC) FILETIME=[3CA20C40:01C76C68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: iab@ietf.org, 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 Not that we have a fire to fight but ARIN members are already "thinking" = about proposing policy to use subnetting with PA. This would be bad as = we all know, and because of this, I strongly feel it would be beneficial = to hunker down and create a solution quickly AND with compitence. = Debating the time frame really is neither here nor there. We just need = to do it. Thank you Marla -----Original Message----- From: Chris L. Morrow [mailto:christopher.morrow@verizonbusiness.com] Sent: Thursday, March 22, 2007 2:41 AM To: Tony Li Cc: iab@ietf.org; ram@iab.org Subject: Re: Workshop report Re: [RAM] Re: Impending publication:draft-iab-raws-report-01.txt On Wed, 21 Mar 2007, Tony Li wrote: > No one was claiming 'dire'. > just to clarify, what is 'dire'? (not asking tony specifically more of a survey question) is 2 years 'dire'? 5 years? 10 years? When looking at design/build/purchase/test/deploy/depreciate timeframes = of +7 years things get 'interesting' quickly. thanks -Chris _______________________________________________ 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 Thu Mar 22 06:03:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUK8g-0002Od-A9; Thu, 22 Mar 2007 06:03:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUK8e-0002Kl-DM for ram@iab.org; Thu, 22 Mar 2007 06:03:20 -0400 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HUK8U-0004XO-E0 for ram@iab.org; Thu, 22 Mar 2007 06:03:20 -0400 Received: from webmail03.lax.untd.com (webmail03.lax.untd.com [10.131.27.143]) by smtpout04.lax.untd.com with SMTP id AABDAEXB2ASMN83S for (sender ); Thu, 22 Mar 2007 03:02:32 -0700 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPcINWq1SZzwVbeLsU150pvhMC26+yBIZtA== Received: (from fergdawg@netzero.net) by webmail03.lax.untd.com (jqueuemail) id MHE8KSF2; Thu, 22 Mar 2007 02:01:41 PST Received: from [130.129.20.210] by webmail03.lax.untd.com with HTTP: Thu, 22 Mar 2007 10:01:23 GMT X-Originating-IP: [130.129.20.210] Mime-Version: 1.0 From: "Fergie" Date: Thu, 22 Mar 2007 10:01:23 GMT To: marla.azinger@frontiercorp.com Subject: RE: Workshop report Re: [RAM] Re: Impending publication:draft-iab-raws -report-01.txt X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20070322.020141.8794.2546396@webmail03.lax.untd.com> X-ContentStamp: 6:3:1037652071 X-MAIL-INFO: 15de1ad3df3a1a3adecbde6393ca2ba7a7333b2ea7af5a93babbbeefaaf7f71a1e77abd3 X-UNTD-Peer-Info: 10.131.27.143|webmail03.lax.untd.com|webmail03.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: tli@cisco.com, iab@ietf.org, 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 -- "Azinger, Marla" wrote: >Not that we have a fire to fight but ARIN members are already "thinking" about proposing policy to use subnetting with PA. This would be bad as we all know, and because of this, I strongly feel it would be beneficial to hunker down and create a solution quickly AND with compitence. Debating the time frame really is neither here nor there. We just need to do it. > Marla, By 'subnetting', do you mean "sub-allocation'? Cheers, - ferg -- "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 Thu Mar 22 06:07: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 1HUKCG-0005bQ-94; Thu, 22 Mar 2007 06:07:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUKCE-0005ay-NM for ram@iab.org; Thu, 22 Mar 2007 06:07:02 -0400 Received: from mail02.frontiercorp.com ([66.133.172.20] helo=frontiercorp.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUKCD-0006LY-Ep for ram@iab.org; Thu, 22 Mar 2007 06:07:02 -0400 Received: from ([10.160.67.161]) by mail02.frontiercorp.com with ESMTP id KP-AXMBT.140335772; Thu, 22 Mar 2007 06:10:30 -0400 Received: from nyrofcs2ke2k01.corp.pvt ([10.160.64.140]) by NYROFCS2KE2K04.corp.pvt with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Mar 2007 06:06:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Workshop report Re: [RAM] Re: Impending publication:draft-iab-raws-report-01.txt Date: Thu, 22 Mar 2007 06:06:40 -0400 Message-ID: <454810F09B5AA04E9D78D13A5C39028A023EF663@nyrofcs2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Workshop report Re: [RAM] Re: Impending publication:draft-iab-raws-report-01.txt Thread-Index: AcdsaU3DhLa3AGr+QcK/SXTOwcWEvQAACw7g From: "Azinger, Marla" To: "Fergie" X-OriginalArrivalTime: 22 Mar 2007 10:06:38.0749 (UTC) FILETIME=[C81454D0:01C76C69] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tli@cisco.com, iab@ietf.org, 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 Sorry for the bad terminology. Letting more specifics within PA = allocations through the filters. Policy wordsmithing would need to be = done and wouldnt read exactly that way, but the end result would be = letting more specifics with PA through filters. Thank you Marla -----Original Message----- From: Fergie [mailto:fergdawg@netzero.net] Sent: Thursday, March 22, 2007 3:01 AM To: Azinger, Marla Cc: christopher.morrow@verizonbusiness.com; tli@cisco.com; iab@ietf.org; ram@iab.org Subject: RE: Workshop report Re: [RAM] Re: Impending publication:draft-iab-raws-report-01.txt -- "Azinger, Marla" wrote: >Not that we have a fire to fight but ARIN members are already "thinking" about proposing policy to use subnetting with PA. This would be bad as we all know, and because of this, I strongly feel it would be beneficial to hunker down and create a solution quickly AND with compitence. Debating the time frame really is neither here nor there. We just need to do it. > Marla, By 'subnetting', do you mean "sub-allocation'? Cheers, - ferg -- "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 Thu Mar 22 06:28: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 1HUKWT-0001RZ-30; Thu, 22 Mar 2007 06:27:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUKWR-0001R0-1h for ram@iab.org; Thu, 22 Mar 2007 06:27:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUKWP-0003wz-QK for ram@iab.org; Thu, 22 Mar 2007 06:27:55 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 22 Mar 2007 06:27:54 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2MARr3I002631; Thu, 22 Mar 2007 06:27:53 -0400 Received: from elear-mac.cisco.com (rtp-vpn2-182.cisco.com [10.82.240.182]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2MARmlG011061; Thu, 22 Mar 2007 10:27:52 GMT Message-ID: <46025A25.4080307@cisco.com> Date: Thu, 22 Mar 2007 11:27:49 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: ram@iab.org, Internet Area 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=851; t=1174559273; x=1175423273; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Please=20be=20more=20specific=20about=20the=20problem |Sender:=20 |To:=20ram@iab.org,=20Internet=20Area=20; bh=05wx9su1pKlxCR01HB6hc5hBRMZ7YgTiNHBdnY2x/YI=; b=NqxXitbsc/IuNGVjdh92kukzMmANUi+SUyh2pZ9AmIHNGwKRvVaV5Ibbgkz3I4fj91B+Z/Ey sZPO/vgCvWPXVNTdVo7khmpLT5IHxLasi9+0J5BAihbEMgMFkBsBvdFR; Authentication-Results: rtp-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [RAM] Please be more specific about the problem 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 With the routing and internet areas working on ID/Locator split and the security and application areas taking notice, can we please be more specific about what problem we think we're solving? Specifically: * Are we concerned about routing table size? Is there a cache limitation? or * are we concerned about routing entropy on the wire? and/or * are we concerned about other control plane entropy internal to the router associated with routing? or * are we concerned about something else? Please provide data and analysis to support your statement. A URL is sufficient. If we do not agree that we have enough data and analysis, perhaps our next step should be to get the data and do the analysis. The lack of data and analysis in this week's presentations was extremely disturbing. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 07:07: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 1HUL6C-0002Vw-Qu; Thu, 22 Mar 2007 07:04:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUL6B-0002Tv-5H for ram@iab.org; Thu, 22 Mar 2007 07:04:51 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUL5w-0004hr-OD for ram@iab.org; Thu, 22 Mar 2007 07:04:51 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 912B4198690; Thu, 22 Mar 2007 13:04:33 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id F158519867C; Thu, 22 Mar 2007 13:04:32 +0200 (EET) Message-ID: <460262BF.20305@piuha.net> Date: Thu, 22 Mar 2007 12:04:31 +0100 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: "Azinger, Marla" Subject: Re: Workshop report Re: [RAM] Re: Impending publication:draft-iab-raws-report-01.txt References: <454810F09B5AA04E9D78D13A5C39028A01A3DDEB@nyrofcs2ke2k01.corp.pvt> In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01A3DDEB@nyrofcs2ke2k01.corp.pvt> 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: 7bac9cb154eb5790ae3b2913587a40de Cc: Tony Li , iab@ietf.org, 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 > Not that we have a fire to fight but ARIN members are already "thinking" about proposing policy to use subnetting with PA. This would be bad as we all know, and because of this, I strongly feel it would be beneficial to hunker down and create a solution quickly AND with compitence. Debating the time frame really is neither here nor there. We just need to do it. > +1 The hard part is doing the solution. Lets focus more on that. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 07:07: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 1HUL62-0001Xc-1m; Thu, 22 Mar 2007 07:04:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUL5z-0001MW-R4 for ram@iab.org; Thu, 22 Mar 2007 07:04:39 -0400 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HUL5o-0004gh-Ew for ram@iab.org; Thu, 22 Mar 2007 07:04:39 -0400 Received: from webmail03.lax.untd.com (webmail03.lax.untd.com [10.131.27.143]) by smtpout04.lax.untd.com with SMTP id AABDAE2WJAVMWG72 for (sender ); Thu, 22 Mar 2007 04:03:36 -0700 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPcINWq1SZzwVnkWmDsLuXW1it93v/rZNUA== Received: (from fergdawg@netzero.net) by webmail03.lax.untd.com (jqueuemail) id MHFB379Z; Thu, 22 Mar 2007 03:03:05 PST Received: from [130.129.20.210] by webmail03.lax.untd.com with HTTP: Thu, 22 Mar 2007 11:02:59 GMT X-Originating-IP: [130.129.20.210] Mime-Version: 1.0 From: "Fergie" Date: Thu, 22 Mar 2007 11:02:59 GMT To: lear@cisco.com Subject: Re: [RAM] Please be more specific about the problem X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20070322.030305.8794.2546549@webmail03.lax.untd.com> X-ContentStamp: 14:7:281425545 X-MAIL-INFO: 02893db589e17070e109a1b5b0f9a4c045a9f5dd500d2ded0d14f5b44034edb1f5b46d113da98d54248d64a48995d080511905a051a080e58060f05970dddd84d199dd4134f0d4b99dc4e465655121c5c919 X-UNTD-Peer-Info: 10.131.27.143|webmail03.lax.untd.com|webmail03.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: int-area@ietf.org, 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 Lear wrote: >With the routing and internet areas working on ID/Locator split and the= = security and application areas taking notice, can we please be more = specific about what problem we think we're solving? > >Specifically: > > * Are we concerned about routing table size? Is there a cache limitation? or * are we concerned about routing entropy on the wire? and/or * are we concerned about other control plane entropy internal to the= router associated with routing? or * are we concerned about something else? > >Please provide data and analysis to support your statement. A URL is = sufficient. If we do not agree that we have enough data and analysis, = perhaps our next step should be to get the data and do the analysis. = The lack of data and analysis in this week's presentations was extremely= = disturbing. > Eliot, So, I didn't attend the RRG meeting on Saturday, but I've seen Vince's presentation on a couple of occasions: http://www1.ietf.org/mail-archive/web/ram/current/msg00747.html Having said that, and while I cannot personally respond to most of the issues you mention [above], I do think that _at_least_ this [the issues outlined by Vince] weighs heavy on many, if not most, Tier-1 ISP's minds. Not sure if this qualifies as sufficient data & analysis, but... I'd like to hear more from the ISPs, myself. $.02, - ferg -- "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 Thu Mar 22 07:07: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 1HUL6C-0002Vw-Qu; Thu, 22 Mar 2007 07:04:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUL6B-0002Tv-5H for ram@iab.org; Thu, 22 Mar 2007 07:04:51 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUL5w-0004hr-OD for ram@iab.org; Thu, 22 Mar 2007 07:04:51 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 912B4198690; Thu, 22 Mar 2007 13:04:33 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id F158519867C; Thu, 22 Mar 2007 13:04:32 +0200 (EET) Message-ID: <460262BF.20305@piuha.net> Date: Thu, 22 Mar 2007 12:04:31 +0100 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: "Azinger, Marla" Subject: Re: Workshop report Re: [RAM] Re: Impending publication:draft-iab-raws-report-01.txt References: <454810F09B5AA04E9D78D13A5C39028A01A3DDEB@nyrofcs2ke2k01.corp.pvt> In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A01A3DDEB@nyrofcs2ke2k01.corp.pvt> 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: 7bac9cb154eb5790ae3b2913587a40de Cc: Tony Li , iab@ietf.org, 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 > Not that we have a fire to fight but ARIN members are already "thinking" about proposing policy to use subnetting with PA. This would be bad as we all know, and because of this, I strongly feel it would be beneficial to hunker down and create a solution quickly AND with compitence. Debating the time frame really is neither here nor there. We just need to do it. > +1 The hard part is doing the solution. Lets focus more on that. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 07:07: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 1HUL62-0001Xc-1m; Thu, 22 Mar 2007 07:04:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUL5z-0001MW-R4 for ram@iab.org; Thu, 22 Mar 2007 07:04:39 -0400 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HUL5o-0004gh-Ew for ram@iab.org; Thu, 22 Mar 2007 07:04:39 -0400 Received: from webmail03.lax.untd.com (webmail03.lax.untd.com [10.131.27.143]) by smtpout04.lax.untd.com with SMTP id AABDAE2WJAVMWG72 for (sender ); Thu, 22 Mar 2007 04:03:36 -0700 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPcINWq1SZzwVnkWmDsLuXW1it93v/rZNUA== Received: (from fergdawg@netzero.net) by webmail03.lax.untd.com (jqueuemail) id MHFB379Z; Thu, 22 Mar 2007 03:03:05 PST Received: from [130.129.20.210] by webmail03.lax.untd.com with HTTP: Thu, 22 Mar 2007 11:02:59 GMT X-Originating-IP: [130.129.20.210] Mime-Version: 1.0 From: "Fergie" Date: Thu, 22 Mar 2007 11:02:59 GMT To: lear@cisco.com Subject: Re: [RAM] Please be more specific about the problem X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20070322.030305.8794.2546549@webmail03.lax.untd.com> X-ContentStamp: 14:7:281425545 X-MAIL-INFO: 02893db589e17070e109a1b5b0f9a4c045a9f5dd500d2ded0d14f5b44034edb1f5b46d113da98d54248d64a48995d080511905a051a080e58060f05970dddd84d199dd4134f0d4b99dc4e465655121c5c919 X-UNTD-Peer-Info: 10.131.27.143|webmail03.lax.untd.com|webmail03.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: int-area@ietf.org, 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 Lear wrote: >With the routing and internet areas working on ID/Locator split and the= = security and application areas taking notice, can we please be more = specific about what problem we think we're solving? > >Specifically: > > * Are we concerned about routing table size? Is there a cache limitation? or * are we concerned about routing entropy on the wire? and/or * are we concerned about other control plane entropy internal to the= router associated with routing? or * are we concerned about something else? > >Please provide data and analysis to support your statement. A URL is = sufficient. If we do not agree that we have enough data and analysis, = perhaps our next step should be to get the data and do the analysis. = The lack of data and analysis in this week's presentations was extremely= = disturbing. > Eliot, So, I didn't attend the RRG meeting on Saturday, but I've seen Vince's presentation on a couple of occasions: http://www1.ietf.org/mail-archive/web/ram/current/msg00747.html Having said that, and while I cannot personally respond to most of the issues you mention [above], I do think that _at_least_ this [the issues outlined by Vince] weighs heavy on many, if not most, Tier-1 ISP's minds. Not sure if this qualifies as sufficient data & analysis, but... I'd like to hear more from the ISPs, myself. $.02, - ferg -- "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 Thu Mar 22 08:18: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 1HUMDL-00025r-In; Thu, 22 Mar 2007 08:16:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMDE-0001so-6u for ram@iab.org; Thu, 22 Mar 2007 08:16:12 -0400 Received: from xmail04.myhosting.com ([168.144.250.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUMAl-0005FN-K9 for ram@iab.org; Thu, 22 Mar 2007 08:13:40 -0400 Received: (qmail 5503 invoked from network); 22 Mar 2007 12:13:10 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with SMTP for ; 22 Mar 2007 12:13:10 -0000 Message-ID: <4602729D.6040202@cisco.com> Date: Thu, 22 Mar 2007 08:12:13 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Eliot Lear References: <46025A25.4080307@cisco.com> In-Reply-To: <46025A25.4080307@cisco.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Internet Area , ram@iab.org Subject: [RAM] Re: [Int-area] Please be more specific about the problem 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 > * Are we concerned about routing table size? Is there a cache > limitation? or > * are we concerned about routing entropy on the wire? and/or > * are we concerned about other control plane entropy internal to the > router associated with routing? or > * are we concerned about something else? I suspect it is the last--that this problem really revolves around traffic engineering based on injecting longer prefix matches, rather than the routing table size, strictly speaking. The problem is, at the core, I think, that competing organizations have competing traffic engineering requirements, and the primary way to express those competing traffic engineering requirements is through the injection of longer prefixes. I think I've heard it said someplace that only about 1/4 of the typical ISP's table is Internet routes, while the remainder are internally injected or 2547bis, etc. Perhaps someone can confirm or deny this? Based on Vince's presentation, about 50% of the "internet" routing table is actually also injected for traffic engineer. Hence, we get to the point where an overwhelming proportion of any given routing table is there to engineer traffic flow, rather than to provide reachability. If this is true, this puts a new spin on the set of possible solutions. 1. Provide some different form of TE that uses something other than longest match routing. 2. Figure out where the routes injected for TE lose their usefulness, and remove them at that point. 3. Other (more creative) ideas.... I'm not certain how a loc/id split would "solve" this issue, if this is the issue.... One of the reasons I'd like to see a better problem statement is to better understand the actual problem. o Is it TE? o Is it table size? o Is the table size being driven by TE? o Is the table size being driven by sheer numbers of hosts? And then, beyond understanding that, I think it's important to look at the tradeoffs when considering a loc/id split. I'm not saying it's a bad idea, we just need to compare the doo we're stepping in to the doo we're actually in before taking that step. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGAnKdER27sUhU9OQRAg98AKC3AEd0ZxnI9I9BkhvCj1K5iNxVJwCeMEmm qOpUooUP8d28Z/qZB+mI89A= =0Dyw -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 08:30: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 1HUMQO-0002qU-U8; Thu, 22 Mar 2007 08:29:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMQO-0002oD-Em for ram@iab.org; Thu, 22 Mar 2007 08:29:48 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUMQN-0001VA-4T for ram@iab.org; Thu, 22 Mar 2007 08:29:48 -0400 Received: by ug-out-1314.google.com with SMTP id z36so622685uge for ; Thu, 22 Mar 2007 05:29:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:x-mailer:date:to:from:subject:mime-version:content-type:sender:message-id; b=GGGT/SZe18TJ6V+q9T63JcyfkDtAu2S6mRZkkstwIutdCdQCNHhY6iOCRR6n2BnNzCkWCAkeconV5PWF+/dUZ1Y5j7OuEksphOwklAVzoUYIpu6+/KSHva0yZtBqZ3UH3gh96TWNWB3osaBsKoG5TADy57Tzq5HtvuNOb5BiJhw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:x-mailer:date:to:from:subject:mime-version:content-type:sender:message-id; b=ki/Ya7eoExBBdDjTsxPfZWsXiAb5T5Gt2N/hbWfILkzHIxF/QHGdElyAlWEkIFzQfcSVTGdS/xp2F2D7SkFWce8XYOVqYn3W2UDWa0kX0mRUHWtPyeSw/6TP2kNJiSgEVhJvLly2XZfXzvDXZu2I/9uEfOZdx9Vbg/FjNkvRl38= Received: by 10.67.99.1 with SMTP id b1mr4825680ugm.1174566586190; Thu, 22 Mar 2007 05:29:46 -0700 (PDT) Received: from gregory-lt.gmail.com ( [130.129.17.44]) by mx.google.com with ESMTP id 55sm3113567ugq.2007.03.22.05.29.44; Thu, 22 Mar 2007 05:29:45 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2007 05:29:42 -0700 To: ram@iab.org From: lebobits Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <460276b9.668b564d.0959.7848@mx.google.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [RAM] add "services" to list of requirements? 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 Sitting in the Int Area listening, something hit me: Stated already: - need ID's for endpoints, as in: - users (on laptop, shared machine, etc.) - machines (specific desktop machine, server, printer, scanner, camera, etc.) I didn't hear stated yet: - need ID for SERVICES, as in: - smtp services (load balanced, globally, redundant clusters) - some home grown web services which actually uses MANY different protocols to many other different service/locator pairings - a web site (load balanced, globally, redundant clusters) Hope it helps, Gregory Gregory Lebovitz Juniper Networks _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 08:40: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 1HUMZo-0000Nc-1C; Thu, 22 Mar 2007 08:39:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMZl-0000CY-TX; Thu, 22 Mar 2007 08:39:29 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUMZg-0003RV-0Y; Thu, 22 Mar 2007 08:39:29 -0400 Received: from [IPv6:2001:df8::16:20a:95ff:fef5:246e] ([IPv6:2001:df8:0:16:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2MCcXH0067557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Mar 2007 13:38:34 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4602729D.6040202@cisco.com> References: <46025A25.4080307@cisco.com> <4602729D.6040202@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <52F3069E-206C-4A19-A341-8729364679CE@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem Date: Thu, 22 Mar 2007 13:39:00 +0100 To: Russ White X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.2 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: ea4ac80f790299f943f0a53be7e1a21a Cc: Internet Area , 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 22-mrt-2007, at 13:12, Russ White wrote: > I think I've heard it said someplace that only about 1/4 of the > typical > ISP's table is Internet routes, while the remainder are internally > injected or 2547bis, etc. Perhaps someone can confirm or deny this? It has been a while since I've worked at a really large ISP, but yes, the internal routing can be significant. However, there is no clear requirement that you carry all internal stuff everywhere, so the size of this stuff is (or: should be) more managable than the DFZ stuff. > Based on Vince's presentation, about 50% of the "internet" routing > table > is actually also injected for traffic engineer. Hence, we get to the > point where an overwhelming proportion of any given routing table is > there to engineer traffic flow, rather than to provide reachability. Increase in the routing table was 16 or 17 % last year, but the number of prefixes given out by the RIRs increased from 72661 to 78154 or a 7.5% increase. In the RRG meeting saturday it was said that 10M total routes in 2021 is doable, which makes for a factor 25 or so increase in 14 years or 24% per year. I guess we don't have a problem after all, and we certainly don't if we can get rid of this TE or "I'm too dumb to aggregate" stuff. Until everyone and their little sister requests IPv6 PI space and starts multihoming in IPv6, of course. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 08:52: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 1HUMl6-0004Zh-C1; Thu, 22 Mar 2007 08:51:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMl4-0004Zc-Ou for ram@iab.org; Thu, 22 Mar 2007 08:51:10 -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 1HUMkx-0005ky-9c for ram@iab.org; Thu, 22 Mar 2007 08:51:10 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-3.cisco.com with ESMTP; 22 Mar 2007 05:51:04 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l2MCp2aw023746; Thu, 22 Mar 2007 05:51:02 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2MCowwt026205; Thu, 22 Mar 2007 12:51:02 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 08:51:00 -0400 Received: from [127.0.0.1] ([161.44.11.166]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 08:51:00 -0400 Message-ID: <46027BB8.9040701@employees.org> Date: Thu, 22 Mar 2007 08:51:04 -0400 From: Scott W Brim Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: lebobits Subject: Re: [RAM] add "services" to list of requirements? References: <460276b9.668b564d.0959.7848@mx.google.com> In-Reply-To: <460276b9.668b564d.0959.7848@mx.google.com> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Mar 2007 12:51:00.0195 (UTC) FILETIME=[BDF59330:01C76C80] Authentication-Results: sj-dkim-6; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 03/22/2007 08:29 AM, lebobits wrote: > Sitting in the Int Area listening, something hit me: > > Stated already: > - need ID's for endpoints, as in: > - users (on laptop, shared machine, etc.) > - machines (specific desktop machine, server, printer, scanner, > camera, etc.) > > I didn't hear stated yet: > - need ID for SERVICES, as in: > - smtp services (load balanced, globally, redundant clusters) > - some home grown web services which actually uses MANY > different protocols to many other different service/locator pairings > - a web site (load balanced, globally, redundant clusters) Yes, all true. There are many "endpoint" identifiers at many levels. Ultimately they all resolve to (one or more) IP-level routing locators. Some of those identifiers might even act as routing locators in higher layers and different scopes. But all that has always been true. What we need in addition to those service-level identifiers is a way to identify an Internet-level endpoint that is decoupled from its routing locator. We need that because service-level identifiers don't resolve down to the Internet layer, where we want to have control. If I want to connect to a SIP AOR which has multiple presences, I need to be able to identify which of the possible Internet endpoints I want to connect to. swb _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 09:17:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUNAB-0007L4-Us; Thu, 22 Mar 2007 09:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUN8W-0006q0-B6; Thu, 22 Mar 2007 09:15:24 -0400 Received: from petal.blackrose.org ([204.212.44.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUN7S-0003dD-G3; Thu, 22 Mar 2007 09:14:19 -0400 Received: from petal.blackrose.org (petal.blackrose.org [127.0.0.1]) by petal.blackrose.org (8.13.7/8.12.4) with ESMTP id l2MDE6nh006405; Thu, 22 Mar 2007 09:14:06 -0400 Received: (from dorian@localhost) by petal.blackrose.org (8.13.7/8.13.7/Submit) id l2MDE6qe006404; Thu, 22 Mar 2007 09:14:06 -0400 Date: Thu, 22 Mar 2007 09:14:05 -0400 From: Dorian Kim To: Iljitsch van Beijnum Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem Message-ID: <20070322131405.GA6320@blackrose.org> References: <46025A25.4080307@cisco.com> <4602729D.6040202@cisco.com> <52F3069E-206C-4A19-A341-8729364679CE@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52F3069E-206C-4A19-A341-8729364679CE@muada.com> User-Agent: Mutt/1.4.2.2i X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0rc3 (petal.blackrose.org [127.0.0.1]); Thu, 22 Mar 2007 09:14:06 -0400 (EDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Thu, 22 Mar 2007 09:17:07 -0400 Cc: ram@iab.org, Internet Area 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 Thu, Mar 22, 2007 at 01:39:00PM +0100, Iljitsch van Beijnum wrote: > On 22-mrt-2007, at 13:12, Russ White wrote: > > >I think I've heard it said someplace that only about 1/4 of the > >typical > >ISP's table is Internet routes, while the remainder are internally > >injected or 2547bis, etc. Perhaps someone can confirm or deny this? > > However, there is no clear > requirement that you carry all internal stuff everywhere, so the size > of this stuff is (or: should be) more managable than the DFZ stuff. This does not reflect the realities of tier 1 ISP networks I'm familiar with. Internal state, whether it's more specific routes, paths, VRFs whatever, cannot be constrained so easily within a tier 1 ISP's network. Furthermore, much of this is "the way it should be" since as poor as the state of aggregation is, DFZ represents a summarisation of the more specifics that float around inside the ISP networks. -dorian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 09:17:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUN9X-000709-HI; Thu, 22 Mar 2007 09:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUKx6-0007rm-PI for ram@iab.org; Thu, 22 Mar 2007 06:55:28 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUKx3-0001mh-Qt for ram@iab.org; Thu, 22 Mar 2007 06:55:28 -0400 Received: by py-out-1112.google.com with SMTP id a25so277421pyi for ; Thu, 22 Mar 2007 03:55:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:x-mailer:date:to:from:subject:mime-version:content-type:message-id; b=W7PkdC4oGu2bpwFLxUz0zoWyIOyQJCui3cInwkiO+8RozoxSY/uGvWazZwIBHQcXgXvtCw9JRKEqrOzUXMdb02PtuKbTCQkz1o81d7w7scn/yReCydbZaebPmTtaTzNN5L1WJHYd4GgPOR3mo8nnqklGdn6ODzqu58MKdHMmbs4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:x-mailer:date:to:from:subject:mime-version:content-type:message-id; b=LkW291tAAsskPTPIu80Xn8tKJh4tFvWGBDcpm/hcjGRv9qsWDWDkTaskQu9PnqblaMDDNLn1EqkVtmXyTlzq37m/s9euBDBuXpjoap3WNbUKrX4RmXTJT3JoqOrsAUJeqp+T1qJzXHq8Qd8Eo1f9IgLt0YiGNsg1pU85BVEVm48= Received: by 10.35.38.17 with SMTP id q17mr3359307pyj.1174560925183; Thu, 22 Mar 2007 03:55:25 -0700 (PDT) Received: from gregory-lt.gmail.com ( [130.129.17.44]) by mx.google.com with ESMTP id n44sm5996943pyh.2007.03.22.03.55.23; Thu, 22 Mar 2007 03:55:24 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2007 03:55:21 -0700 To: ram@iab.org From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4602609c.7806f8f6.7f38.6da2@mx.google.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Thu, 22 Mar 2007 09:16:26 -0400 Subject: [RAM] add services to list of requirements 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 Sitting in the Int Area listening, something hit me: Stated already: - need ID's for endpoints, as in: - users (on laptop, shared machine, etc.) - machines (specific desktop machine, server, printer, scanner, camera, etc.) I didn't hear stated yet: - need ID for SERVICES, as in: - smtp services (load balanced, globally, redundant) - some home grown web services which actually uses MANY different protocols to many other different service/locator pairings - a web site Hope it helps, lebo Gregory Lebovitz Juniper Networks _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 09:17:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUNAB-0007L4-Us; Thu, 22 Mar 2007 09:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUN8W-0006q0-B6; Thu, 22 Mar 2007 09:15:24 -0400 Received: from petal.blackrose.org ([204.212.44.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUN7S-0003dD-G3; Thu, 22 Mar 2007 09:14:19 -0400 Received: from petal.blackrose.org (petal.blackrose.org [127.0.0.1]) by petal.blackrose.org (8.13.7/8.12.4) with ESMTP id l2MDE6nh006405; Thu, 22 Mar 2007 09:14:06 -0400 Received: (from dorian@localhost) by petal.blackrose.org (8.13.7/8.13.7/Submit) id l2MDE6qe006404; Thu, 22 Mar 2007 09:14:06 -0400 Date: Thu, 22 Mar 2007 09:14:05 -0400 From: Dorian Kim To: Iljitsch van Beijnum Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem Message-ID: <20070322131405.GA6320@blackrose.org> References: <46025A25.4080307@cisco.com> <4602729D.6040202@cisco.com> <52F3069E-206C-4A19-A341-8729364679CE@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52F3069E-206C-4A19-A341-8729364679CE@muada.com> User-Agent: Mutt/1.4.2.2i X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0rc3 (petal.blackrose.org [127.0.0.1]); Thu, 22 Mar 2007 09:14:06 -0400 (EDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Thu, 22 Mar 2007 09:17:07 -0400 Cc: ram@iab.org, Internet Area 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 Thu, Mar 22, 2007 at 01:39:00PM +0100, Iljitsch van Beijnum wrote: > On 22-mrt-2007, at 13:12, Russ White wrote: > > >I think I've heard it said someplace that only about 1/4 of the > >typical > >ISP's table is Internet routes, while the remainder are internally > >injected or 2547bis, etc. Perhaps someone can confirm or deny this? > > However, there is no clear > requirement that you carry all internal stuff everywhere, so the size > of this stuff is (or: should be) more managable than the DFZ stuff. This does not reflect the realities of tier 1 ISP networks I'm familiar with. Internal state, whether it's more specific routes, paths, VRFs whatever, cannot be constrained so easily within a tier 1 ISP's network. Furthermore, much of this is "the way it should be" since as poor as the state of aggregation is, DFZ represents a summarisation of the more specifics that float around inside the ISP networks. -dorian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 09:17:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUN9X-000709-HI; Thu, 22 Mar 2007 09:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUKx6-0007rm-PI for ram@iab.org; Thu, 22 Mar 2007 06:55:28 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUKx3-0001mh-Qt for ram@iab.org; Thu, 22 Mar 2007 06:55:28 -0400 Received: by py-out-1112.google.com with SMTP id a25so277421pyi for ; Thu, 22 Mar 2007 03:55:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:x-mailer:date:to:from:subject:mime-version:content-type:message-id; b=W7PkdC4oGu2bpwFLxUz0zoWyIOyQJCui3cInwkiO+8RozoxSY/uGvWazZwIBHQcXgXvtCw9JRKEqrOzUXMdb02PtuKbTCQkz1o81d7w7scn/yReCydbZaebPmTtaTzNN5L1WJHYd4GgPOR3mo8nnqklGdn6ODzqu58MKdHMmbs4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:x-mailer:date:to:from:subject:mime-version:content-type:message-id; b=LkW291tAAsskPTPIu80Xn8tKJh4tFvWGBDcpm/hcjGRv9qsWDWDkTaskQu9PnqblaMDDNLn1EqkVtmXyTlzq37m/s9euBDBuXpjoap3WNbUKrX4RmXTJT3JoqOrsAUJeqp+T1qJzXHq8Qd8Eo1f9IgLt0YiGNsg1pU85BVEVm48= Received: by 10.35.38.17 with SMTP id q17mr3359307pyj.1174560925183; Thu, 22 Mar 2007 03:55:25 -0700 (PDT) Received: from gregory-lt.gmail.com ( [130.129.17.44]) by mx.google.com with ESMTP id n44sm5996943pyh.2007.03.22.03.55.23; Thu, 22 Mar 2007 03:55:24 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2007 03:55:21 -0700 To: ram@iab.org From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4602609c.7806f8f6.7f38.6da2@mx.google.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Thu, 22 Mar 2007 09:16:26 -0400 Subject: [RAM] add services to list of requirements 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 Sitting in the Int Area listening, something hit me: Stated already: - need ID's for endpoints, as in: - users (on laptop, shared machine, etc.) - machines (specific desktop machine, server, printer, scanner, camera, etc.) I didn't hear stated yet: - need ID for SERVICES, as in: - smtp services (load balanced, globally, redundant) - some home grown web services which actually uses MANY different protocols to many other different service/locator pairings - a web site Hope it helps, lebo Gregory Lebovitz Juniper Networks _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 09:17:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUN9X-00070a-Ob; Thu, 22 Mar 2007 09:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMKO-0001zU-EM for ram@iab.org; Thu, 22 Mar 2007 08:23:36 -0400 Received: from wx-out-0506.google.com ([66.249.82.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUMKN-0008OZ-7f for ram@iab.org; Thu, 22 Mar 2007 08:23:36 -0400 Received: by wx-out-0506.google.com with SMTP id h29so764175wxd for ; Thu, 22 Mar 2007 05:23:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:x-mailer:date:to:from:subject:mime-version:content-type:message-id; b=HeVIzd3FfSBXb9lUMN/BOVFpYIsQQUYjqVVzDeIpbMbeAWNgTz/Dm7xdgnM9C+bkFDRyht1yznHkJuoGhNT3DARG8+pK7XWwgdDx/aQ+Hu4IajRyyYFuI+2CYu0MLM+E+hCbb9o+31K+JNOD02yMYD3MphnXoQQ+xY3I3MndkwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:x-mailer:date:to:from:subject:mime-version:content-type:message-id; b=cxw73VqjhWcyAu9sTf1SL5c5jJuEEJPXRnnStYyIhP/R7eD6tQAMVzdlOsyLcCFqlOuStpIGdRIKE+/Z7p1uUKtK2uprMSG6uVBLyJy7YdfSHu+CzfgiEFvR8jrSF3bKFlO7uXBHb5W7e9UMhINsvz29HqcJOS5RxWyv7aAwrso= Received: by 10.90.88.13 with SMTP id l13mr3295136agb.1174566214975; Thu, 22 Mar 2007 05:23:34 -0700 (PDT) Received: from gregory-lt.gmail.com ( [130.129.17.44]) by mx.google.com with ESMTP id 26sm3311474aga.2007.03.22.05.23.33; Thu, 22 Mar 2007 05:23:34 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2007 05:23:29 -0700 To: ram@iab.org From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <46027546.025e494a.413d.ffffc7b5@mx.google.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Thu, 22 Mar 2007 09:16:26 -0400 Subject: [RAM] add "services" to list of requirements? 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 Sitting in the Int Area listening, something hit me: Stated already: - need ID's for endpoints, as in: - users (on laptop, shared machine, etc.) - machines (specific desktop machine, server, printer, scanner, camera, etc.) I didn't hear stated yet: - need ID for SERVICES, as in: - smtp services (load balanced, globally, redundant clusters) - some home grown web services which actually uses MANY different protocols to many other different service/locator pairings - a web site (load balanced, globally, redundant clusters) Hope it helps, Gregory Gregory Lebovitz Juniper Networks _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 09:17:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUN9X-000704-AA; Thu, 22 Mar 2007 09:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUKoW-0004ZM-7p; Thu, 22 Mar 2007 06:46:36 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUKoK-00074s-LF; Thu, 22 Mar 2007 06:46:26 -0400 Received: from c-24-16-66-58.hsd1.mn.comcast.net ([24.16.66.58] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.63) (envelope-from ) id 1HUKoK-0009mE-7T; Thu, 22 Mar 2007 06:46:24 -0400 Received: by internaut.com (Postfix, from userid 1000) id B61E743EE8; Thu, 22 Mar 2007 03:46:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id A772943EDD; Thu, 22 Mar 2007 03:46:26 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.66.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Thu, 22 Mar 2007 03:46:26 -0700 (PDT) From: Bernard Aboba To: Eliot Lear In-Reply-To: <46025A25.4080307@cisco.com> Message-ID: References: <46025A25.4080307@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Thu, 22 Mar 2007 09:16:26 -0400 Cc: Internet Area , ram@iab.org Subject: [RAM] Re: [Int-area] Please be more specific about the problem 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 > The lack of data and analysis in this week's presentations was extremely > disturbing. In considering protocol solutions to performance problems it is often very difficult to come to consensus because: a. Performance data is often highly dependent on the implementations being studied, and therefore it is often unclear whether the conclusions hold universally. b. There are often multiple solutions available to the problem, some of which will perform better than others in given use cases. Without agreement on the use cases, it can therefore be difficult to agree which solutions are superior, even if the performance data itself is unassailable (which is itself rare). The end result of this is that in practice, standards bodies often face the choice of waiting for completion of a protracted requirements/performance test development phase, or allowing work to proceed without a solid basis, under the theory that "the market will sort it out". While the latter approach frequently results in solutions in search of a problem, this may at times be preferrable to deadlock. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 09:20: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 1HUNCP-0000JO-5L; Thu, 22 Mar 2007 09:19:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUNCN-0000IK-EA; Thu, 22 Mar 2007 09:19:23 -0400 Received: from petal.blackrose.org ([204.212.44.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUNC4-0006PC-V8; Thu, 22 Mar 2007 09:19:23 -0400 Received: from petal.blackrose.org (petal.blackrose.org [127.0.0.1]) by petal.blackrose.org (8.13.7/8.12.4) with ESMTP id l2MDJ3nD006476; Thu, 22 Mar 2007 09:19:03 -0400 Received: (from dorian@localhost) by petal.blackrose.org (8.13.7/8.13.7/Submit) id l2MDJ36M006475; Thu, 22 Mar 2007 09:19:03 -0400 Date: Thu, 22 Mar 2007 09:19:03 -0400 From: Dorian Kim To: ram@iab.org Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem Message-ID: <20070322131903.GB6320@blackrose.org> References: <46025A25.4080307@cisco.com> <4602729D.6040202@cisco.com> <52F3069E-206C-4A19-A341-8729364679CE@muada.com> <20070322131405.GA6320@blackrose.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070322131405.GA6320@blackrose.org> User-Agent: Mutt/1.4.2.2i X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0rc3 (petal.blackrose.org [127.0.0.1]); Thu, 22 Mar 2007 09:19:03 -0400 (EDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Internet Area 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 Thu, Mar 22, 2007 at 01:39:00PM +0100, Iljitsch van Beijnum wrote: > > On 22-mrt-2007, at 13:12, Russ White wrote: > > > > >I think I've heard it said someplace that only about 1/4 of the > > >typical > > >ISP's table is Internet routes, while the remainder are internally > > >injected or 2547bis, etc. Perhaps someone can confirm or deny this? > > > > However, there is no clear > > requirement that you carry all internal stuff everywhere, so the size > > of this stuff is (or: should be) more managable than the DFZ stuff. This does not reflect the realities of tier 1 ISP networks I'm familiar with. Internal state, whether it's more specific routes, paths, VRFs whatever, cannot be constrained so easily within a tier 1 ISP's network. Furthermore, much of this is "the way it should be" since as poor as the state of aggregation is, DFZ represents a summarisation of the more specifics that float around inside the ISP networks. -dorian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 09:20: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 1HUND9-0000ZE-GY; Thu, 22 Mar 2007 09:20:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUN8f-0006uA-Oz for ram@iab.org; Thu, 22 Mar 2007 09:15:34 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUN10-000270-6N for ram@iab.org; Thu, 22 Mar 2007 09:07:39 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9D2E986AE9; Thu, 22 Mar 2007 09:07:35 -0400 (EDT) To: int-area@ietf.org, ram@iab.org Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem Message-Id: <20070322130735.9D2E986AE9@mercury.lcs.mit.edu> Date: Thu, 22 Mar 2007 09:07:35 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: jnc@mercury.lcs.mit.edu 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: Russ White > I'm not certain how a loc/id split would "solve" this issue, if this is > the issue.... One of the reasons I'd like to see a better problem > statement is to better understand the actual problem. This triggered another design-philosophy thought, if you all will bear with another one of these.... Asking "how will architectural feature X solve problem Y" is not a useful question to ask - iff your goal is to ascertain whether X is a good idea. (If all you're trying to do is solve Y, of course, it is a reasonable question.) Remember my maxim about great architecture: The test of great architecture is not how well it does things it was designed to do, but how well it does things it was never expected to handle. So you can never really evaluate architecture by asking "does it do the things listed in this requirements document", or anything like that. The way to evaluate architectural structures, qua architecture, is to say "does this somehow encapsulate some essential vision of how things really are, or ought to be, organized" - think things like stacks and processes, concepts which now seem not just "obvious and intuitive", but "necessary" - but weren't when they were first invented. (For a good time, read early computer designs and see how they did procedure calls - once they understood what a procedure is, of course - the earlist ones didn't even do that.) And along that axis, the location/identity split is clearly a good thing, because at a fundamental level, location and identity are two very different concepts, and it's clear that having one name for both is just going to be fundamentally limiting. And to answer your actual question, IMO the real way to do TE is to support both traffic aggregates (i.e. collections of packets) and paths as first-class objects at the internetworking layer. That way, you can say "this traffic aggregate should take that path" directly, instead of trying to do it indirectly by fiddling with routing tables (the latter technique being something I liken to driving a screw by gripping a flat piece of metal with a pair of vice-grips, because that's the only tool you've got; buy a screwdriver, dude :-). The location/identity split is not really germane to handling TE, any more than, say, queing priorities (another architectural change, albeit a smaller one). It's just a part of the fundamental 'atmosphere' of networking concepts, one which is just not on point when doing TE. What the problems in doing TE *really* are, are a symptom of the over-simplicity of the architecture of the internetworking layer, and the routing (path-finding). That simplicity was a Good Thing in trying to do an initial "test of concept" deployment back in the late 70's, but it's biting us now. Fixing just one of those shortcomings (conflating identity and location) is simply not fixing all of them. No single patch to an existing architecture can do that. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 09:20: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 1HUNCP-0000JO-5L; Thu, 22 Mar 2007 09:19:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUNCN-0000IK-EA; Thu, 22 Mar 2007 09:19:23 -0400 Received: from petal.blackrose.org ([204.212.44.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUNC4-0006PC-V8; Thu, 22 Mar 2007 09:19:23 -0400 Received: from petal.blackrose.org (petal.blackrose.org [127.0.0.1]) by petal.blackrose.org (8.13.7/8.12.4) with ESMTP id l2MDJ3nD006476; Thu, 22 Mar 2007 09:19:03 -0400 Received: (from dorian@localhost) by petal.blackrose.org (8.13.7/8.13.7/Submit) id l2MDJ36M006475; Thu, 22 Mar 2007 09:19:03 -0400 Date: Thu, 22 Mar 2007 09:19:03 -0400 From: Dorian Kim To: ram@iab.org Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem Message-ID: <20070322131903.GB6320@blackrose.org> References: <46025A25.4080307@cisco.com> <4602729D.6040202@cisco.com> <52F3069E-206C-4A19-A341-8729364679CE@muada.com> <20070322131405.GA6320@blackrose.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070322131405.GA6320@blackrose.org> User-Agent: Mutt/1.4.2.2i X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0rc3 (petal.blackrose.org [127.0.0.1]); Thu, 22 Mar 2007 09:19:03 -0400 (EDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Internet Area 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 Thu, Mar 22, 2007 at 01:39:00PM +0100, Iljitsch van Beijnum wrote: > > On 22-mrt-2007, at 13:12, Russ White wrote: > > > > >I think I've heard it said someplace that only about 1/4 of the > > >typical > > >ISP's table is Internet routes, while the remainder are internally > > >injected or 2547bis, etc. Perhaps someone can confirm or deny this? > > > > However, there is no clear > > requirement that you carry all internal stuff everywhere, so the size > > of this stuff is (or: should be) more managable than the DFZ stuff. This does not reflect the realities of tier 1 ISP networks I'm familiar with. Internal state, whether it's more specific routes, paths, VRFs whatever, cannot be constrained so easily within a tier 1 ISP's network. Furthermore, much of this is "the way it should be" since as poor as the state of aggregation is, DFZ represents a summarisation of the more specifics that float around inside the ISP networks. -dorian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 09:20: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 1HUND9-0000ZE-GY; Thu, 22 Mar 2007 09:20:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUN8f-0006uA-Oz for ram@iab.org; Thu, 22 Mar 2007 09:15:34 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUN10-000270-6N for ram@iab.org; Thu, 22 Mar 2007 09:07:39 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9D2E986AE9; Thu, 22 Mar 2007 09:07:35 -0400 (EDT) To: int-area@ietf.org, ram@iab.org Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem Message-Id: <20070322130735.9D2E986AE9@mercury.lcs.mit.edu> Date: Thu, 22 Mar 2007 09:07:35 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: jnc@mercury.lcs.mit.edu 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: Russ White > I'm not certain how a loc/id split would "solve" this issue, if this is > the issue.... One of the reasons I'd like to see a better problem > statement is to better understand the actual problem. This triggered another design-philosophy thought, if you all will bear with another one of these.... Asking "how will architectural feature X solve problem Y" is not a useful question to ask - iff your goal is to ascertain whether X is a good idea. (If all you're trying to do is solve Y, of course, it is a reasonable question.) Remember my maxim about great architecture: The test of great architecture is not how well it does things it was designed to do, but how well it does things it was never expected to handle. So you can never really evaluate architecture by asking "does it do the things listed in this requirements document", or anything like that. The way to evaluate architectural structures, qua architecture, is to say "does this somehow encapsulate some essential vision of how things really are, or ought to be, organized" - think things like stacks and processes, concepts which now seem not just "obvious and intuitive", but "necessary" - but weren't when they were first invented. (For a good time, read early computer designs and see how they did procedure calls - once they understood what a procedure is, of course - the earlist ones didn't even do that.) And along that axis, the location/identity split is clearly a good thing, because at a fundamental level, location and identity are two very different concepts, and it's clear that having one name for both is just going to be fundamentally limiting. And to answer your actual question, IMO the real way to do TE is to support both traffic aggregates (i.e. collections of packets) and paths as first-class objects at the internetworking layer. That way, you can say "this traffic aggregate should take that path" directly, instead of trying to do it indirectly by fiddling with routing tables (the latter technique being something I liken to driving a screw by gripping a flat piece of metal with a pair of vice-grips, because that's the only tool you've got; buy a screwdriver, dude :-). The location/identity split is not really germane to handling TE, any more than, say, queing priorities (another architectural change, albeit a smaller one). It's just a part of the fundamental 'atmosphere' of networking concepts, one which is just not on point when doing TE. What the problems in doing TE *really* are, are a symptom of the over-simplicity of the architecture of the internetworking layer, and the routing (path-finding). That simplicity was a Good Thing in trying to do an initial "test of concept" deployment back in the late 70's, but it's biting us now. Fixing just one of those shortcomings (conflating identity and location) is simply not fixing all of them. No single patch to an existing architecture can do that. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 10: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 1HUODu-00081J-B4; Thu, 22 Mar 2007 10:25:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUODs-00080e-IU; Thu, 22 Mar 2007 10:25:00 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUODs-0007kx-3E; Thu, 22 Mar 2007 10:25:00 -0400 Received: from [IPv6:2001:df8::16:20a:95ff:fef5:246e] ([IPv6:2001:df8:0:16:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2MEOTsI069306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Mar 2007 15:24:29 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <218BF3BA-9B4B-4E82-8234-36BEF304A331@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Date: Thu, 22 Mar 2007 15:24:55 +0100 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.2 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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: int-area@ietf.org Subject: [RAM] My remarks at the microphone 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 Let me repeat and expand upon my remarks just now. -- The place -- There are three obvious places to implement the locator/identifier (or locator/locator) mapping: 1. in hosts 2. in site border routers / middleboxes 3. in ISP networks In hosts is extremely problematic for a number of reasons: - costs and benefits aren't aligned with regard to the routing table issue, so not enough incentive for deployment - the number of hosts is enormous, updating them all takes prohibitive amounts of time - middleboxes and the like make any kind of change, especially with IPv4, very hard to deploy - there is no reason to assume that renumbering locators will be significantly easier than renumbering host addresses is today On the other hand, the advantage of working in hosts is that the additional state is least problematic there because hosts already keep state for all their sessions/associations. Site border routers or middleboxes share the economic issue and, to a lesser degree, the renumbering issue. Middleboxes (but not site border routers) also generally store state for active sessions and the number of sessions is still relatively limited at this point, so a chaching mechanism is still workable here. Performing the mapping in ISP networks has the very important benefit that cost and benefit are aligned, but at this point, the number of sessions flowing through any individual box is almost certainly too large to be safely handled using caching, so flooding of at least some state for all possible destinations is probably required. Additionally, it's not too problematic to push something that started in ISP networks to middleboxes, and something in middleboxes to hosts, but the other way around is often not possible or very hard. See the issues with shim6 proxying -- A mapping system -- As I said, BGP and DNS can both be considered to be mapping protocols, and they both have some aspects that are desirable and some aspects that are problematic. The DNS can carry millions of entries in a single zone (with some effort) and probably an unlimited number of entries given a suitable hierarchy. However, it requires on-demand operation, which means dropped packets and/or delays at session start and the risk of caches (see SQL slammer worm experiences). The DNS also has caching so not only do you not get any updates when something changes, if you (as an application) go out and ask again, you get a cached answer. BGP on the other hand floods everything but has serious scaling issues and suffers from the problem that local optimizations introduce global state. Additionally, BGP is a routing protocol so it needs to know about paths and loops, which means that information in BGP must be updated at each hop. What we need in a new mapping system is the scalability and parallelism of the DNS coupled with the immediacy of BGP, but where BGP distributes next hop information, the new mapping system should distribute "last hop" information. Margaret (I think) brought up the point that if a new mapping system contains all the information that's now in BGP, we haven't really gained anything. That's not necessarily true. The problem with BGP is not so much the amount of information, or even the number of updates, but rather, the need for all this information to come together in one place: the RIB of every core router. If the new system is designed to allow the easy splitting up the full state of the entire internet over an arbitrary number of devices, each of those devices can live at the knee in the price/performance curve. An important goal in a new mapping protocol should be the ability to flood updates where needed, i.e., in the case of multihoming where the fact that one ISP is no longer usable is important to know for all correspondents of the multihomed site, and the more deliberate propagation of information that isn't time sensitive, such as the movement of a single homed user of PI space. Additionally, such a protocol can supply hooks for obtaining more detailed information directly from the source. This would be useful in mobility, where a destination is always reachable through the home agent, and a slight delay in optimizing the path towards the current location of the mobile node isn't problematic. In the same way, the flooded mapping state could be highly aggregated and therefore make packets flow rather suboptimally, but as soon as communciation starts, better mappings can be negotiated end-to-end. If we go for a "jack up" solution to the routing scalability problem, existing PI prefixes can be jacked up one by one, facilitating gradual deployment. However, the mapping mechanism could be made forward compatible with more advanced identifier/locator splits so the benefits would be in both the short-medium and long-medium terms. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 10:32:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOKF-0001fO-Vm; Thu, 22 Mar 2007 10:31:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOKF-0001ez-9C for ram@iab.org; Thu, 22 Mar 2007 10:31:35 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUOKE-0000C1-2O for ram@iab.org; Thu, 22 Mar 2007 10:31:35 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Mar 2007 10:31:34 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2MEVXhx026924; Thu, 22 Mar 2007 10:31:33 -0400 Received: from [70.0.42.146] (rtp-vpn3-278.cisco.com [10.82.217.24]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2MEVTlG004516; Thu, 22 Mar 2007 14:31:30 GMT In-Reply-To: <218BF3BA-9B4B-4E82-8234-36BEF304A331@muada.com> References: <218BF3BA-9B4B-4E82-8234-36BEF304A331@muada.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <311668FE-5DB2-4785-A4B6-1A52C6EEEC28@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] My remarks at the microphone Date: Thu, 22 Mar 2007 07:31:22 -0700 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1036; t=1174573893; x=1175437893; c=relaxed/simple; s=rtpdkim2001; 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]=20My=20remarks=20at=20the=20microphone |Sender:=20 |To:=20Iljitsch=20van=20Beijnum=20; bh=wtfG4WxsVTEufJ4GmXwcOdAGYM/lsYH90g+yn5jOBdI=; b=fjyhnxZBSHdE/YMu2TXmALB2HcATSIRIELjrRGZLC5h+M59uEkXrXr9LX30W/Pi5M4X+tEPU sbxKh4nPU7SWgWPbNpoRlymHcPjDYzE5mXt73affSW/7617zHQMj69B0; Authentication-Results: rtp-dkim-2; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: int-area@ietf.org, 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 Mar 22, 2007, at 7:24 AM, Iljitsch van Beijnum wrote: > What we need in a new mapping system is the scalability and > parallelism of the DNS coupled with the immediacy of BGP, but where > BGP distributes next hop information, the new mapping system should > distribute "last hop" information. Given the state of the global DNS in terms of scaling/resiliency/ maintenance/patching (I'm not talking about the roots or the TLDs, but Everything Else), it's important to note that whatever this system is that you're positing probably shouldn't be a sysadmin-type thing that runs on general-purpose computers, but rather in-band in terms of the networking infrastructure itself. This is where the various proposals to actually rely upon the DNS for lookups fall down. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 11:13: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 1HUOwj-0008UA-SH; Thu, 22 Mar 2007 11:11:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOwi-0008Ts-OC for ram@iab.org; Thu, 22 Mar 2007 11:11:20 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUOw3-0001ah-1R for ram@iab.org; Thu, 22 Mar 2007 11:11:20 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 45AA2198690; Thu, 22 Mar 2007 17:10:35 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0450019867C; Thu, 22 Mar 2007 17:10:32 +0200 (EET) Message-ID: <46029C68.4090802@piuha.net> Date: Thu, 22 Mar 2007 16:10:32 +0100 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: jordi.palet@consulintel.es References: In-Reply-To: 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: 08170828343bcf1325e4a0fb4584481c Cc: Internet Area , ram@iab.org Subject: [RAM] Re: [Int-area] About today BOF and possible interim meeting X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ram@iab.org List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > However, this will only be true IF and ONLY IF it is fixed in the next 2-3 > days, possible giving several choices for dates in May. > We are aware of this, and are trying to come up with the details. Early analysis indicates that there's likely not a lot of room for multiple choices, given other meetings in that time frame for the operator community, IAB, etc. We should have something to tell you by Monday or Tuesday. (Please keep talking about this or id-locator separation issues on the ram list; follow-ups directed there.) Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 11: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 1HUPCU-0005gF-K8; Thu, 22 Mar 2007 11:27:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUPCS-0005fk-Hy for ram@iab.org; Thu, 22 Mar 2007 11:27:36 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUPCA-0002B3-L9 for ram@iab.org; Thu, 22 Mar 2007 11:27:36 -0400 Received: by wr-out-0506.google.com with SMTP id 68so634083wri for ; Thu, 22 Mar 2007 08:27:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=awX1r0vw1H6FUbp3/8VJ1FeWLA6Bs0d2Vs3ITcgHa8F8s/FtFk0XM7yw/XZTXA5AsKHqg3qvLW6H12gD3NxQnfSVrvmOOkb4gAcqNrLvn/1dLgxPz1Gu/EciK01IBq+lTCDjTMOedakWQPt/Y9Ars64hemVqZyrRw7wa1LrpKQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=oVauWTtdetAvZ4stTXQje9l3Yg5ZZXNtp9bOPeL+7FdjTvqWpMjcM8pfAU+R2/d2W41yU2I9FUHTXSXnMuUykYOWceC0kChytJR6t/2w/RuAdD8hX9MIQ0ArV0jXvF7SKFmsHDeQGruC/S4heDW8P1INuJsar7ga5i2fOgmzpZc= Received: by 10.115.93.16 with SMTP id v16mr644679wal.1174577235850; Thu, 22 Mar 2007 08:27:15 -0700 (PDT) Received: by 10.114.210.19 with HTTP; Thu, 22 Mar 2007 08:27:15 -0700 (PDT) Message-ID: Date: Thu, 22 Mar 2007 08:27:15 -0700 From: "lebo bits" To: "Scott W Brim" Subject: Re: [RAM] add "services" to list of requirements? In-Reply-To: <46027BB8.9040701@employees.org> MIME-Version: 1.0 References: <460276b9.668b564d.0959.7848@mx.google.com> <46027BB8.9040701@employees.org> X-Google-Sender-Auth: e8b7006d021f69aa X-Spam-Score: 0.1 (/) 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: , Content-Type: multipart/mixed; boundary="===============0000349799==" Errors-To: ram-bounces@iab.org --===============0000349799== Content-Type: multipart/alternative; boundary="----=_Part_206144_6398154.1174577235769" ------=_Part_206144_6398154.1174577235769 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 3/22/07, Scott W Brim wrote: > > On 03/22/2007 08:29 AM, lebobits wrote: > > Sitting in the Int Area listening, something hit me: > > > > Stated already: > > - need ID's for endpoints, as in: > > - users (on laptop, shared machine, etc.) > > - machines (specific desktop machine, server, printer, scanner, > > camera, etc.) > > > > I didn't hear stated yet: > > - need ID for SERVICES, as in: > > - smtp services (load balanced, globally, redundant clusters) > > - some home grown web services which actually uses MANY > > different protocols to many other different service/locator pairings > > - a web site (load balanced, globally, redundant clusters) > > Yes, all true. There are many "endpoint" identifiers at many levels. > Ultimately they all resolve to (one or more) IP-level routing > locators. Some of those identifiers might even act as routing > locators in higher layers and different scopes. But all that has > always been true. What we need in addition to those service-level > identifiers is a way to identify an Internet-level endpoint that is > decoupled from its routing locator. We need that because > service-level identifiers don't resolve down to the Internet layer, > where we want to have control. If I want to connect to a SIP AOR > which has multiple presences, I need to be able to identify which of > the possible Internet endpoints I want to connect to. perhaps then we need some middle-glue which can take the service-level (in your words) identifier and bind it to a specific protocol identifier, then bind that to the appropriate "Internet-level" endpoint(s). ?? Gregory swb > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks ------=_Part_206144_6398154.1174577235769 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 3/22/07, Scott W Brim <swb@employees.org> wrote:
On 03/22/2007 08:29 AM, lebobits wrote:
> Sitting in the Int Area listening, something hit me:
>
> Stated already:
>  - need ID's for endpoints, as in:
>       - users (on laptop, shared machine, etc.)
>       - machines (specific desktop machine, server, printer, scanner,
> camera, etc.)
>
> I didn't hear stated yet:
>  - need ID for SERVICES, as in:
>         - smtp services (load balanced, globally, redundant clusters)
>         - some home grown web services which actually uses MANY
> different protocols to many other different service/locator pairings
>         - a web site (load balanced, globally, redundant clusters)

Yes, all true.  There are many "endpoint" identifiers at many levels.
Ultimately they all resolve to (one or more) IP-level routing
locators.  Some of those identifiers might even act as routing
locators in higher layers and different scopes.  But all that has
always been true.  What we need in addition to those service-level
identifiers is a way to identify an Internet-level endpoint that is
decoupled from its routing locator.  We need that because
service-level identifiers don't resolve down to the Internet layer,
where we want to have control.  If I want to connect to a SIP AOR
which has multiple presences, I need to be able to identify which of
the possible Internet endpoints I want to connect to.
 
perhaps then we need some middle-glue which can take the service-level (in your words) identifier and bind it to a specific protocol identifier, then bind that to the appropriate "Internet-level" endpoint(s). ??
 
Gregory

swb



--
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks ------=_Part_206144_6398154.1174577235769-- --===============0000349799== 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 --===============0000349799==-- From ram-bounces@iab.org Thu Mar 22 11:46: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 1HUPTf-0006b1-Iz; Thu, 22 Mar 2007 11:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUPTd-0006aA-UO for ram@iab.org; Thu, 22 Mar 2007 11:45:21 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUPTP-0007Gp-5A for ram@iab.org; Thu, 22 Mar 2007 11:45:21 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 15:45:06 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 15:39:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Mar 2007 15:39:17 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] My remarks at the microphone Thread-Index: AcdsjghvRvEKBEoRRYOht04dv9aFLgACXpM5 References: <218BF3BA-9B4B-4E82-8234-36BEF304A331@muada.com> From: To: , X-OriginalArrivalTime: 22 Mar 2007 15:39:20.0866 (UTC) FILETIME=[426DA820:01C76C98] X-Spam-Score: 0.2 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: int-area@ietf.org Subject: [RAM] RE: [Int-area] My remarks at the microphone 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 the place: =20 isn't it possible that the solution might be implemented in different = places depending on the functionality to be suported? Thus, the loc id = split might go all the way to the hosts if they want in-session handover = or host multi-homing, but not in other cases?=20 =20 performing this near the ISP edge does not feel like a problem to me - = have you seen what they are doing with DPI?! =20 louise ________________________________ From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Thu 22/03/2007 14:24 To: ram@iab.org Cc: int-area@ietf.org Subject: [Int-area] My remarks at the microphone Let me repeat and expand upon my remarks just now. -- The place -- There are three obvious places to implement the locator/identifier=20 (or locator/locator) mapping: 1. in hosts 2. in site border routers / middleboxes 3. in ISP networks In hosts is extremely problematic for a number of reasons: - costs and benefits aren't aligned with regard to the routing table=20 issue, so not enough incentive for deployment - the number of hosts is enormous, updating them all takes=20 prohibitive amounts of time - middleboxes and the like make any kind of change, especially with=20 IPv4, very hard to deploy - there is no reason to assume that renumbering locators will be=20 significantly easier than renumbering host addresses is today On the other hand, the advantage of working in hosts is that the=20 additional state is least problematic there because hosts already=20 keep state for all their sessions/associations. Site border routers or middleboxes share the economic issue and, to a=20 lesser degree, the renumbering issue. Middleboxes (but not site=20 border routers) also generally store state for active sessions and=20 the number of sessions is still relatively limited at this point, so=20 a chaching mechanism is still workable here. Performing the mapping in ISP networks has the very important benefit=20 that cost and benefit are aligned, but at this point, the number of=20 sessions flowing through any individual box is almost certainly too=20 large to be safely handled using caching, so flooding of at least=20 some state for all possible destinations is probably required. Additionally, it's not too problematic to push something that started=20 in ISP networks to middleboxes, and something in middleboxes to=20 hosts, but the other way around is often not possible or very hard.=20 See the issues with shim6 proxying -- A mapping system -- As I said, BGP and DNS can both be considered to be mapping=20 protocols, and they both have some aspects that are desirable and=20 some aspects that are problematic. The DNS can carry millions of entries in a single zone (with some=20 effort) and probably an unlimited number of entries given a suitable=20 hierarchy. However, it requires on-demand operation, which means=20 dropped packets and/or delays at session start and the risk of caches=20 (see SQL slammer worm experiences). The DNS also has caching so not=20 only do you not get any updates when something changes, if you (as an=20 application) go out and ask again, you get a cached answer. BGP on the other hand floods everything but has serious scaling=20 issues and suffers from the problem that local optimizations=20 introduce global state. Additionally, BGP is a routing protocol so it=20 needs to know about paths and loops, which means that information in=20 BGP must be updated at each hop. What we need in a new mapping system is the scalability and=20 parallelism of the DNS coupled with the immediacy of BGP, but where=20 BGP distributes next hop information, the new mapping system should=20 distribute "last hop" information. Margaret (I think) brought up the point that if a new mapping system=20 contains all the information that's now in BGP, we haven't really=20 gained anything. That's not necessarily true. The problem with BGP is=20 not so much the amount of information, or even the number of updates,=20 but rather, the need for all this information to come together in one=20 place: the RIB of every core router. If the new system is designed to=20 allow the easy splitting up the full state of the entire internet=20 over an arbitrary number of devices, each of those devices can live=20 at the knee in the price/performance curve. An important goal in a new mapping protocol should be the ability to=20 flood updates where needed, i.e., in the case of multihoming where=20 the fact that one ISP is no longer usable is important to know for=20 all correspondents of the multihomed site, and the more deliberate=20 propagation of information that isn't time sensitive, such as the=20 movement of a single homed user of PI space. Additionally, such a=20 protocol can supply hooks for obtaining more detailed information=20 directly from the source. This would be useful in mobility, where a=20 destination is always reachable through the home agent, and a slight=20 delay in optimizing the path towards the current location of the=20 mobile node isn't problematic. In the same way, the flooded mapping=20 state could be highly aggregated and therefore make packets flow=20 rather suboptimally, but as soon as communciation starts, better=20 mappings can be negotiated end-to-end. If we go for a "jack up" solution to the routing scalability problem,=20 existing PI prefixes can be jacked up one by one, facilitating=20 gradual deployment. However, the mapping mechanism could be made=20 forward compatible with more advanced identifier/locator splits so=20 the benefits would be in both the short-medium and long-medium terms. _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 11:52: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 1HUPad-0002QA-DQ; Thu, 22 Mar 2007 11:52:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUPBV-0005JB-OL; Thu, 22 Mar 2007 11:26:38 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUP8W-00011z-2P; Thu, 22 Mar 2007 11:23:35 -0400 Received: from [130.129.21.21] (dhcp-1515.ietf68.org [130.129.21.21]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l2MFNFba021397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 07:23:17 -0800 Message-ID: <46029F5C.9050809@dcrocker.net> Date: Thu, 22 Mar 2007 16:23:08 +0100 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Internet Area Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem References: <46025A25.4080307@cisco.com> <4602729D.6040202@cisco.com> <52F3069E-206C-4A19-A341-8729364679CE@muada.com> In-Reply-To: <52F3069E-206C-4A19-A341-8729364679CE@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Folks, > Until everyone and their little sister requests IPv6 PI space and starts > multihoming in IPv6, of course. (Everything below has been said many times, by many people, over the last 5 years... and probably a lot longer. I'm repeating these things a) because they seem to be needed for the current discussion, and b) to suggest that they offer practical, simplifying guidance for divide-and-conquor on the daunting list of issues that the current effort seems to emcompass.) Once upon a time, an IP Address referred to an interface. (In some circles, it still might, but in discussions surrounding multihoming, and some other topics, it seems not to be quite so constrained.) If that idea is re-asserted, then multihoming *almost* not an IP-level problem and certainly not a routing problem. When the host is single-homed, but its network is multihomed, then the single interface will see different addresses. Treat these as virtual, independent interfaces, and the host-vs-net multihoming problem reverts to the problem of a multi-homed host. (I wasn't kidding when I said that everything has been said many times by many others.) IP's job is to get a datagram from one interface to another, and it does that quite nicely. OK, there are scaling issues within that specific task, and they are serious. But they have to do with routing, rather than higher-level constructs. INT and RTG need to work on this problem. Traffice engineering requires retaining control of flows, but now streams of associated data may travel over multiple paths. Here, too, something additional needs to be done, since the IP Address is no longer a constant for the flow. Probably this needs a flow identifier in each datagram. Perhaps the identifier needs to be globally unique and perhaps it doesn't. It certainly isn't likely to need the identifier to have long-term persistence and it probably does not even need any sort of mapping (mechanism) between identifier and the IP Address (ie, locator) in the infrastructure, since the datagrams already have the locators in them. So, a mapping mechanism is needed in the source and destination hosts, but nowhere else. In other words, it is used for linkage into a transport context rather than for rendezvous between hosts. If the identifier is not persistent, the mapping well might be computational rather than from a mapping server. So, the remaining problems of having IP Addresses be used as identifiers are not IP's. They belong to other areas. (Or, rather, Areas...) For example, multi-homing is naturally a transport problem -- and it is fine if the solution is embodied as a shim above IP, since it also can be characterized as a shim *below* transport... The change needed is for transport to be comfortable with having datagrams of the same connection show different source and/or destination addresses. Hmmm. Sounds like the same flow identifier, but maybe not, since here it's only used by the ends of the connection. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 12:24: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 1HUQ4h-0007Rz-Cj; Thu, 22 Mar 2007 12:23:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUQ4f-0007Qp-MG; Thu, 22 Mar 2007 12:23:37 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUQ4e-0000JD-AE; Thu, 22 Mar 2007 12:23:37 -0400 Received: from [130.129.21.21] (dhcp-1515.ietf68.org [130.129.21.21]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l2MGNNe1004924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2007 08:23:28 -0800 Message-ID: <4602AD77.6050302@dcrocker.net> Date: Thu, 22 Mar 2007 17:23:19 +0100 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem References: <20070322130735.9D2E986AE9@mercury.lcs.mit.edu> In-Reply-To: <20070322130735.9D2E986AE9@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: int-area@ietf.org, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Noel Chiappa wrote: > Remember my maxim about great architecture: The test of great architecture is > not how well it does things it was designed to do, but how well it does > things it was never expected to handle. So you can never really evaluate > architecture by asking "does it do the things listed in this requirements > document", or anything like that. If the answer to the question is: It does the things listed in this requirements document *badly*, then you know that you should not consider the architecture further. If the answer to the question is: I do not know, then you know the architecture will not have near-term utility. This sounds like a useful, first-stage filter. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 12:53: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 1HUQUU-0001oI-Jg; Thu, 22 Mar 2007 12:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUQUT-0001nu-8X for ram@iab.org; Thu, 22 Mar 2007 12:50:17 -0400 Received: from smtp-1.dynsipr.ucl.ac.be ([130.104.4.1] helo=smtp1.sgsi.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUQUQ-0004zf-JT for ram@iab.org; Thu, 22 Mar 2007 12:50:17 -0400 Received: from smtp1.sgsi.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP id B8E7C2C6DA; Thu, 22 Mar 2007 17:50:04 +0100 (CET) Received: from [130.104.229.95] (unknown [130.104.229.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP; Thu, 22 Mar 2007 17:50:04 +0100 (CET) Message-ID: <4602B3B8.4050605@info.ucl.ac.be> Date: Thu, 22 Mar 2007 17:50:00 +0100 From: Olivier Bonaventure User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ White Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem References: <46025A25.4080307@cisco.com> <4602729D.6040202@cisco.com> In-Reply-To: <4602729D.6040202@cisco.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=UTF-8 X-AV-Checked: ClamAV using ClamSMTP X-SGSI-MailScanner: Found to be clean X-SGSI-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-22.5, requis 5, autolearn=not spam, BAYES_00 -2.60, RCVD_AUTH_OK -20.00, SARE_FROM_SPAM_WORD3 0.10, SPF_HELO_PASS -0.00) X-SGSI-From: bonaventure@info.ucl.ac.be X-SGSI-Spam-Status: No Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Internet Area , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bonaventure@info.ucl.ac.be List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Russ, >=20 >=20 >>> * Are we concerned about routing table size? Is there a cache >>> limitation? or >>> * are we concerned about routing entropy on the wire? and/or >>> * are we concerned about other control plane entropy internal to th= e >>> router associated with routing? or >>> * are we concerned about something else? ... > If this is true, this puts a new spin on the set of possible solutions. >=20 > 1. Provide some different form of TE that uses something other than > longest match routing. >=20 > 2. Figure out where the routes injected for TE lose their usefulness, > and remove them at that point. >=20 > 3. Other (more creative) ideas.... >=20 > I'm not certain how a loc/id split would "solve" this issue, if this is > the issue.... One of the reasons I'd like to see a better problem > statement is to better understand the actual problem. The loc/id split would clearly provide new ways of performing traffic engineering without any impact on the BGP routing tables. I showed two examples (improving delays and increasing the number of paths) in my presentation at the RRG meeting on Saturday, available on the RRG wiki and also on http://www.info.ucl.ac.be/~obo/pres.html For additional results based on the shim6 approach, but applicable yo other loc/id separation mechanisms, see for example the PhD thesis written by Cedric de Launois : C. de Launois, Unleashing Tra=EF=AC=83c Engineering for IPv6 Multihomed S= ites, Sept. 2005 http://alumni.info.ucl.ac.be/delaunoi/publications.html Olivier --=20 CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/~obo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 13:01: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 1HUQej-000271-Az; Thu, 22 Mar 2007 13:00:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUQei-00026v-Ap for ram@iab.org; Thu, 22 Mar 2007 13:00:52 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUQec-00079W-Uf for ram@iab.org; Thu, 22 Mar 2007 13:00:52 -0400 Received: from [130.129.16.254] by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50002442185.msg for ; Thu, 22 Mar 2007 17:18:45 +0100 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 22 Mar 2007 17:21:16 +0100 From: JORDI PALET MARTINEZ To: "ram@iab.org" Message-ID: Thread-Topic: [Int-area] About today BOF and possible interim meeting Thread-Index: Acdsnh2QXACY3tiREduclwAX8sYbNQ== In-Reply-To: <46029C68.4090802@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:070322:ram@iab.org::sssXQZRACapr5//Q:0000000Gzc X-MDRemoteIP: 130.129.16.254 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, 22 Mar 2007 17:57:22 +0100 X-MDAV-Processed: consulintel.es, Thu, 22 Mar 2007 17:57:33 +0100 X-Spam-Score: 0.5 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Internet Area Subject: [RAM] Re: [Int-area] About today BOF and possible interim meeting 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 Well, with all the respect, I disagree. A single choice is not an option, at least not a fair one. I've already indicated two possible choices. I you've a third one, ask in the list the interested participants to state their preference in the next 72 hours or so, and then take a decision. Regards, Jordi > De: Jari Arkko > Responder a: "ram@iab.org" > Fecha: Thu, 22 Mar 2007 16:10:32 +0100 > Para: > CC: Internet Area , "ram@iab.org" > Asunto: Re: [Int-area] About today BOF and possible interim meeting > > >> However, this will only be true IF and ONLY IF it is fixed in the next 2-3 >> days, possible giving several choices for dates in May. >> > We are aware of this, and are trying to come up with the details. Early > analysis indicates that there's likely not a lot of room for multiple > choices, given other meetings in that time frame for the operator > community, IAB, etc. We should have something to tell you by > Monday or Tuesday. > > (Please keep talking about this or id-locator separation issues on the > ram list; follow-ups directed there.) > > Jari > ********************************************** 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 From ram-bounces@iab.org Thu Mar 22 13:37: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 1HURDO-0005sQ-1Q; Thu, 22 Mar 2007 13:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURDM-0005s9-I0 for ram@iab.org; Thu, 22 Mar 2007 13:36:40 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HURDK-0005aZ-9p for ram@iab.org; Thu, 22 Mar 2007 13:36:40 -0400 Received: from [130.129.18.240] (dhcp-12f0.ietf68.org [130.129.18.240]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 848246454E for ; Thu, 22 Mar 2007 10:36:29 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <460262BF.20305@piuha.net> References: <454810F09B5AA04E9D78D13A5C39028A01A3DDEB@nyrofcs2ke2k01.corp.pvt> <460262BF.20305@piuha.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <280B49D0-D7D5-4BC0-891F-87747D09BCCB@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: Workshop report Re: [RAM] Re: Impending publication:draft-iab-raws-report-01.txt Date: Thu, 22 Mar 2007 11:36:30 -0600 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Mar 22, 2007, at 5:04 AM, Jari Arkko wrote: > >> Not that we have a fire to fight but ARIN members are already >> "thinking" about proposing policy to use subnetting with PA. This >> would be bad as we all know, and because of this, I strongly feel >> it would be beneficial to hunker down and create a solution >> quickly AND with compitence. Debating the time frame really is >> neither here nor there. We just need to do it > > +1 > > The hard part is doing the solution. Lets focus more on that. While I agree with this sentiment on one level, it concerns me that we're not aiming at some common end goal (even with accepting that it's a moving target). Intermediate solutions are necessary (even if that means dual stack, ships in the night, whatever) but if they carry us in a direction that diverges from the (an) end goal, even a seemingly marginal degree, then they're little more than a distraction and we'll wind up putting out another fire (or at least smoke 'n fumes) in another decade. I'm also of the opinion that while intermediate solutions that impose network state are fine, if the end goal isn't aimed at accommodating the end to end principle, then it's off track. In the vein of grandmother quotes this week "If you aim at nothin, you'll quite likely hit it!". And if folks are going to project growth numbers they should carefully consider what those devices are, as I'm quite sure that when going from where we are today to, say, e.g., 10B, some shifts in what constitutes the majority of devices is certain. -danny _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 13:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURNY-0005zV-Qc; Thu, 22 Mar 2007 13:47:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURNX-0005xl-Am for ram@iab.org; Thu, 22 Mar 2007 13:47:11 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HURNV-0006rr-Mv for ram@iab.org; Thu, 22 Mar 2007 13:47:11 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CF797212C7F; Thu, 22 Mar 2007 19:47:03 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 73D03212C49; Thu, 22 Mar 2007 19:47:03 +0200 (EET) In-Reply-To: <46029F5C.9050809@dcrocker.net> References: <46025A25.4080307@cisco.com> <4602729D.6040202@cisco.com> <52F3069E-206C-4A19-A341-8729364679CE@muada.com> <46029F5C.9050809@dcrocker.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13F388B8-027B-4F34-A1D7-622F12709EFD@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem Date: Thu, 22 Mar 2007 18:47:01 +0100 To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Internet Area , 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, A lot of what you wrote (and I don't quote below) has indeed been said many times. However, I think you left unsaid a few important things that have also been said many times in the past. > So, the remaining problems [other than routing table growth and > traffic engineering] of having IP Addresses be used as identifiers > are not IP's. They belong to other areas. (Or, rather, Areas...) What was repeated at least 7 times during this morning's INT are meeting is really a sad piece of history: The majority of today's applications use some derivative of the Berkeley Socket API. The only thing the Berkeley socket API understands (in practice) is IP addresses. The TCP TCBs are also bound to IP addresses; something that, based on our current success, must have been a very good design decision back when it was made. So, if you say that the other problems (like mobility or the use of IP addresses within applications and management systems) belong to other Areas, you are basically stating that both TCP, all applications, and most of our current management systems must be changed since they have been implemented wrongly from today's point of view. Now, I might buy (but don't) that as an architectural statement, but realistically, if our job is to keep the Internet running even when the world is changing, I'm afraid that we do and will need backwards compatibility. (See Section 3.3. of draft- nikander-ram-ilse-00.txt) [Footnote: The reason why I don't quite buy your argument even architecturally is that I believe that for most functions there is a natural level of granularity (e.g. subnet, host, or application) where they apply. If we are able to implement them within the protocols that act on that granularity, we can gain in terms of simplicity, protocol efficiency, and security.] > For example, multi-homing is naturally a transport problem -- and > it is fine if the solution is embodied as a shim above IP, since it > also can be characterized as a shim *below* transport... I would only agree if there was a clear distinction that the IP layer works in terms of interfaces and it is the transport that works in terms of hosts (and not even then for site multi-homing). But that is not really the case. The legacy transport (TCP and UDP) have no concept of a host. Architecturally (and I am referring back to Salzer), the architecture has been missing, from the beginning, host- granularity identifiers. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 13:52:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURRZ-000222-QR; Thu, 22 Mar 2007 13:51:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURRY-00021i-Lr for ram@iab.org; Thu, 22 Mar 2007 13:51:20 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HURRV-0000AZ-K8 for ram@iab.org; Thu, 22 Mar 2007 13:51:20 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Mar 2007 18:51:17 +0100 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 l2MHpGlT027277; Thu, 22 Mar 2007 18:51:16 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4344.cisco.com [10.61.80.247]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2MHpBlZ007631; Thu, 22 Mar 2007 17:51:12 GMT Message-ID: <4602C211.4020902@cisco.com> Date: Thu, 22 Mar 2007 18:51:13 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem References: <20070322130735.9D2E986AE9@mercury.lcs.mit.edu> In-Reply-To: <20070322130735.9D2E986AE9@mercury.lcs.mit.edu> 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=1762; t=1174585876; x=1175449876; 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]=20Re=3A=20[Int-area]=20Please=20be=20more=20spe cific=20about=20the=20problem |Sender:=20; bh=gf9fAt90uq5n7a09CezbLvjzBkNpISDnK7cAzw1jMr8=; b=eK2EfiYWP0EQ6AQLVBhZMGdI4kp1X+WbFU8XTvnYPiql9WXEa4l/wr7xWeaHPNtTiw5N+otd NoB0C/T8ZhclYqwH0xyv/Of7buzzwVU7SbnmUXj+hQqrshz4r1hu9AAM; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: int-area@ietf.org, 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 Noel, An engineering problem has been raised, and while a new architecture can be a solution to an engineering problem, I want to understand just how far we have to go to fix the engineering problem. In order to do that I have to understand the engineering problem better. And so I wonder if someone can point me to the presentations that were given at the routing area so I can see what we're talking about. Amazingly, in the seven or so presentations I've taken on this topic, only one of them had any data at all (thank you Tony & Vince) about routing growth, but even it did not answer this question: is our primary concern control plane churn in the form of memory bandwidth or memory size? I've gotten an oral answer of "both", but at least some data is needed in order to answer the question of what sort of characteristics any mapping from id to loc must have. That was the point that I amongst others tried to make at the mike, today. Which brings me to Bernard's point: > a. Performance data is often highly dependent on the implementations being > studied, and therefore it is often unclear whether the conclusions hold > universally. > > b. There are often multiple solutions available to the problem, some of > which will perform better than others in given use cases. Without > agreement on the use cases, it can therefore be difficult to agree which > solutions are superior, even if the performance data itself is > unassailable (which is itself rare). Understood, and so if you can tell me what "the problem" is with some reason to believe so, I believe we will have gotten over this hurdle. I believe therefore the questions I asked are not beyond the bounds of reason. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 14:05:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURd3-0001ZA-B1; Thu, 22 Mar 2007 14:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURd2-0001VF-05 for ram@iab.org; Thu, 22 Mar 2007 14:03:12 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HURcz-0002mC-MX for ram@iab.org; Thu, 22 Mar 2007 14:03:11 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 22 Mar 2007 11:03:07 -0700 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 l2MI37IJ003269; Thu, 22 Mar 2007 11:03:07 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2MI2pwx000958; Thu, 22 Mar 2007 18:03:06 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); Thu, 22 Mar 2007 11:02:58 -0700 Received: from [130.129.17.126] ([10.21.88.150]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 11:02:57 -0700 In-Reply-To: <218BF3BA-9B4B-4E82-8234-36BEF304A331@muada.com> References: <218BF3BA-9B4B-4E82-8234-36BEF304A331@muada.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75E7FB2B-26F6-45DD-A7EB-3273D708938B@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] My remarks at the microphone Date: Thu, 22 Mar 2007 11:02:53 -0700 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Mar 2007 18:02:57.0636 (UTC) FILETIME=[526C6A40:01C76CAC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=917; t=1174586587; x=1175450587; c=relaxed/simple; s=sjdkim7002; 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]=20My=20remarks=20at=20the=20microphone |Sender:=20; bh=3MWlGr4l/uyAMr8YKaf52eahGVqzFIYXZikmyVDSEcg=; b=pFiFO9R5LPcCSgE8mz+tNq5RmmXCzCgSVZIvOwa43ooDmMbH+w/o0aJUVSJXjG8bEP6AurjI LxlfpbSFmsawo9xZ0tEApeD5EAubVPl/4kkwVqrl/q+gEvHQBwrCW0JW; Authentication-Results: sj-dkim-7; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: int-area@ietf.org, 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 > As I said, BGP and DNS can both be considered to be mapping > protocols, and they both have some aspects that are desirable and > some aspects that are problematic. After this week, I have concluded that both BGP and DNS *should not* be considered. However, we could model something new off of BGP and DNS. That is, a pull versus push model or a combination of both. > BGP on the other hand floods everything but has serious scaling > issues and suffers from the problem that local optimizations > introduce global state. BGP does not flood everything. On eBGP peering it sends only best paths. > What we need in a new mapping system is the scalability and > parallelism of the DNS coupled with the immediacy of BGP, but where > BGP distributes next hop information, the new mapping system should > distribute "last hop" information. What is last-hop information? Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 14:16: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 1HURpH-00007G-OX; Thu, 22 Mar 2007 14:15:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURpH-00006q-0a for ram@iab.org; Thu, 22 Mar 2007 14:15:51 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HURpF-0003a0-Ol for ram@iab.org; Thu, 22 Mar 2007 14:15:50 -0400 Received: from [10.0.1.235] (dhcp-4009.ietf68.org[130.129.64.9]) by comcast.net (sccrmhc11) with SMTP id <20070322181545011009taske>; Thu, 22 Mar 2007 18:15:46 +0000 In-Reply-To: <4602C211.4020902@cisco.com> References: <20070322130735.9D2E986AE9@mercury.lcs.mit.edu> <4602C211.4020902@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] Re: [Int-area] Please be more specific about the problem Date: Thu, 22 Mar 2007 19:15:24 +0100 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: int-area@ietf.org, Noel Chiappa , 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, > is our primary concern control plane churn in the form of memory > bandwidth or memory size? My primary concern at this point is memory latency in the RIB. You should be careful to note the difference between bandwidth and latency and it's impact on performance. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 14:16: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 1HURp5-0008Vy-F7; Thu, 22 Mar 2007 14:15:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURp4-0008To-JQ for ram@iab.org; Thu, 22 Mar 2007 14:15:38 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HURoz-0003XO-2h for ram@iab.org; Thu, 22 Mar 2007 14:15:38 -0400 Received: from pmismtp01.mcilink.com ([166.37.158.161]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JFB00A20HDT2B@firewall.mci.com> for ram@iab.org; Thu, 22 Mar 2007 18:15:30 +0000 (GMT) Received: from pmismtp01.mcilink.com ([127.0.0.1]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JFB00BQFHDTQF@pmismtp01.mcilink.com> for ram@iab.org; Thu, 22 Mar 2007 18:15:29 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JFB00D02HDTA8@pmismtp01.mcilink.com> for ram@iab.org; Thu, 22 Mar 2007 18:15:29 +0000 (GMT) Date: Thu, 22 Mar 2007 18:15:29 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: Workshop report Re: [RAM] Re: Impending publication:draft-iab-raws-report-01.txt In-reply-to: <280B49D0-D7D5-4BC0-891F-87747D09BCCB@tcb.net> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: ram@iab.org Message-id: MIME-versioFrom ram-bounces@iab.org Thu Mar 22 14:16: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 1HURpH-00007G-OX; Thu, 22 Mar 2007 14:15:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURpH-00006q-0a for ram@iab.org; Thu, 22 Mar 2007 14:15:51 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HURpF-0003a0-Ol for ram@iab.org; Thu, 22 Mar 2007 14:15:50 -0400 Received: from [10.0.1.235] (dhcp-4009.ietf68.org[130.129.64.9]) by comcast.net (sccrmhc11) with SMTP id <20070322181545011009taske>; Thu, 22 Mar 2007 18:15:46 +0000 In-Reply-To: <4602C211.4020902@cisco.com> References: <20070322130735.9D2E986AE9@mercury.lcs.mit.edu> <4602C211.4020902@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] Re: [Int-area] Please be more specific about the problem Date: Thu, 22 Mar 2007 19:15:24 +0100 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: int-area@ietf.org, Noel Chiappa , 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, > is our primary concern control plane churn in the form of memory > bandwidth or memory size? My primary concern at this point is memory latency in the RIB. You should be careful to note the difference between bandwidth and latency and it's impact on performance. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 14:16: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 1HURp5-0008Vy-F7; Thu, 22 Mar 2007 14:15:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURp4-0008To-JQ for ram@iab.org; Thu, 22 Mar 2007 14:15:38 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HURoz-0003XO-2h for ram@iab.org; Thu, 22 Mar 2007 14:15:38 -0400 Received: from pmismtp01.mcilink.com ([166.37.158.161]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JFB00A20HDT2B@firewall.mci.com> for ram@iab.org; Thu, 22 Mar 2007 18:15:30 +0000 (GMT) Received: from pmismtp01.mcilink.com ([127.0.0.1]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JFB00BQFHDTQF@pmismtp01.mcilink.com> for ram@iab.org; Thu, 22 Mar 2007 18:15:29 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by pmismtp01.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JFB00D02HDTA8@pmismtp01.mcilink.com> for ram@iab.org; Thu, 22 Mar 2007 18:15:29 +0000 (GMT) Date: Thu, 22 Mar 2007 18:15:29 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: Workshop report Re: [RAM] Re: Impending publication:draft-iab-raws-report-01.txt In-reply-to: <280B49D0-D7D5-4BC0-891F-87747D09BCCB@tcb.net> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: ram@iab.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <454810F09B5AA04E9D78D13A5C39028A01A3DDEB@nyrofcs2ke2k01.corp.pvt> <460262BF.20305@piuha.net> <280B49D0-D7D5-4BC0-891F-87747D09BCCB@tcb.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Thu, 22 Mar 2007, Danny McPherson wrote: > > On Mar 22, 2007, at 5:04 AM, Jari Arkko wrote: > > > > >> Not that we have a fire to fight but ARIN members are already > >> "thinking" about proposing policy to use subnetting with PA. This > >> would be bad as we all know, and because of this, I strongly feel > >> it would be beneficial to hunker down and create a solution > >> quickly AND with compitence. Debating the time frame really is > >> neither here nor there. We just need to do it > > > > +1 > > > > The hard part is doing the solution. Lets focus more on that. Jari, I agree about the 'lets move forward on a solution' (whole heartedly actually) but my question originally was to frame 'long term' and 'short term' properly. > > While I agree with this sentiment on one level, it concerns > me that we're not aiming at some common end goal (even > with accepting that it's a moving target). I was hoping that part of the goal included a rough timeframe :) I think we can noddle around on this for a very long time, some timeframe to bracket the work seems useful. Perhaps the IAB has that in mind? or in it's process? or the IETF does? (have a built-in TTL for work I mean) anyway.. forward progress, it's a good thing :) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram n: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <454810F09B5AA04E9D78D13A5C39028A01A3DDEB@nyrofcs2ke2k01.corp.pvt> <460262BF.20305@piuha.net> <280B49D0-D7D5-4BC0-891F-87747D09BCCB@tcb.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Thu, 22 Mar 2007, Danny McPherson wrote: > > On Mar 22, 2007, at 5:04 AM, Jari Arkko wrote: > > > > >> Not that we have a fire to fight but ARIN members are already > >> "thinking" about proposing policy to use subnetting with PA. This > >> would be bad as we all know, and because of this, I strongly feel > >> it would be beneficial to hunker down and create a solution > >> quickly AND with compitence. Debating the time frame really is > >> neither here nor there. We just need to do it > > > > +1 > > > > The hard part is doing the solution. Lets focus more on that. Jari, I agree about the 'lets move forward on a solution' (whole heartedly actually) but my question originally was to frame 'long term' and 'short term' properly. > > While I agree with this sentiment on one level, it concerns > me that we're not aiming at some common end goal (even > with accepting that it's a moving target). I was hoping that part of the goal included a rough timeframe :) I think we can noddle around on this for a very long time, some timeframe to bracket the work seems useful. Perhaps the IAB has that in mind? or in it's process? or the IETF does? (have a built-in TTL for work I mean) anyway.. forward progress, it's a good thing :) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 14:23: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 1HURvn-0004XQ-29; Thu, 22 Mar 2007 14:22:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURvl-0004XI-MA for ram@iab.org; Thu, 22 Mar 2007 14:22:33 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1] helo=pmesmtp01.mci.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HURvk-0003xe-B1 for ram@iab.org; Thu, 22 Mar 2007 14:22:33 -0400 Received: from pmismtp02.mcilink.com ([166.37.158.162]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JFB0024SHPHZR@firewall.mci.com> for ram@iab.org; Thu, 22 Mar 2007 18:22:29 +0000 (GMT) Received: from pmismtp02.mcilink.com ([127.0.0.1]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JFB00502HPH0J@pmismtp02.mcilink.com> for ram@iab.org; Thu, 22 Mar 2007 18:22:29 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by pmismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JFB004JHHPG6W@pmismtp02.mcilink.com> for ram@iab.org; Thu, 22 Mar 2007 18:22:29 +0000 (GMT) Date: Thu, 22 Mar 2007 18:22:28 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] RE: [Int-area] My remarks at the microphone In-reply-to: X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: louise.burness@bt.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <218BF3BA-9B4B-4E82-8234-36BEF304A331@muada.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: int-area@ietf.org, 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 Thu, 22 Mar 2007 louise.burness@bt.com wrote: > performing this near the ISP edge does not feel like a problem to me - > have you seen what they are doing with DPI?! have you seen the cost of the DPI boxes? :) I'm not sure I've got 500k USD/gig of traffic, nevermind no one wants to support DPI on an ChOC48->DS1... _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 14:26: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 1HURyc-0005ZL-RP; Thu, 22 Mar 2007 14:25:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HURyb-0005Z9-IV for ram@iab.org; Thu, 22 Mar 2007 14:25:29 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HURyZ-0004Dx-4y for ram@iab.org; Thu, 22 Mar 2007 14:25:29 -0400 Received: from [130.129.18.240] (dhcp-12f0.ietf68.org [130.129.18.240]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 9D24164445; Thu, 22 Mar 2007 11:25:18 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <46025A25.4080307@cisco.com> References: <46025A25.4080307@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03C46099-B6CB-4F07-92DC-42692340E732@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Subject: Re: [RAM] Please be more specific about the problem Date: Thu, 22 Mar 2007 12:25:18 -0600 To: ram@iab.org, Internet Area X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 On Mar 22, 2007, at 4:27 AM, Eliot Lear wrote: > With the routing and internet areas working on ID/Locator split and > the security and application areas taking notice, can we please be > more specific about what problem we think we're solving? > > Specifically: > > * Are we concerned about routing table size? Is there a cache > limitation? or > * are we concerned about routing entropy on the wire? and/or > * are we concerned about other control plane entropy internal to > the > router associated with routing? or > * are we concerned about something else? I suspect one way to look at this is to ask what's going to break first? While I agree that FIB scaling issues exist, I suspect many of the folks most concerned today operate routers in the networks closest to the "Internet Core". As the denseness of interconnection in the global routing system increases, it's the internal network devices that are hit the hardest. Everyone is looking at external paths and unique FIB entries and there's clearly concerning growth there, but from all the data I've seen it's the number of *paths* that are internal to a given AS that are the most immediate problem. As I mentioned at the microphone in IDR, the number of paths on 'PEs' in SP networks seems to be anywhere from 300-800k (~1.5 - 3x the number of unique prefixes in the routing system), while in the core of the network the number of paths on iBGP speakers is often 10-30x the number of unique prefixes in the routing system (e.g., 3 'tier 1 ISPs' polled yesterday had from 3-5 million unique paths on 'core' route reflectors; I had routers with 2 million paths 7 years ago). This is largely dictated by the requirement that route reflection and/or AS confederations are needed to avoid a full mesh, and then one, or two, or three more are required to provide redundancy, and then that external denseness in interconnection increases and you end up with a ton of churn and update duplication, driving CPU cycles, DRAM, and even data<->control plane bandwidth problems. Furthermore, functions like BGP update packing are negatively impacted because of the number of unique path attributes grows (e.g., originiator IDs, cluster IDs, IGP metrics, MEDs, next hops, etc..). Then we make protocol changes to optimize implementations (e.g., BGP Route Reflection changes regarding whether client knows it's a client and whether RR reflects routes learned from clients back to that client) and the system level problem only gets worse. So you can either make things flatter, add more hierarchy, modify the protocol to support new scaling mechanisms, or design a new protocol -- all of the above introduce the usual offshoots (e.g., TCP session state v. route oscillation probability, etc.) In short, the growth curve for internal BGP speaker paths is much steeper than that of unique prefixes and general RIB data, and is highly topologically dependent. I believe there is opportunity here for short-term protocols, implementation and operational gains. FWIW, I believe that loc/ID split makes sense longer term, as discussed in another email I posted here earlier. -danny _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 14:51: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 1HUSMK-0000ND-Nk; Thu, 22 Mar 2007 14:50:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUSMJ-0000N8-W4 for ram@iab.org; Thu, 22 Mar 2007 14:49:59 -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 1HUSMI-0002yk-IN for ram@iab.org; Thu, 22 Mar 2007 14:49:59 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l2MIaGpJ025497; Thu, 22 Mar 2007 10:36:20 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Thu, 22 Mar 2007 11:49:19 -0700 X-PGP-Universal: processed; by terminus.local on Thu, 22 Mar 2007 11:49:19 -0700 In-Reply-To: <4602C211.4020902@cisco.com> References: <20070322130735.9D2E986AE9@mercury.lcs.mit.edu> <4602C211.4020902@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <2A3B6CC7-9804-4363-BB84-59807727C15B@virtualized.org> From: David Conrad Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem Date: Thu, 22 Mar 2007 11:49:14 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Mar 22, 2007, at 10:51 AM, Eliot Lear wrote: > An engineering problem has been raised, and while a new > architecture can be a solution to an engineering problem, I want to > understand just how far we have to go to fix the engineering problem. Actually, I think a better description of the situation is that we're seeing yet another symptom (or symptoms) of an underlying architecture problem and we're looking for yet another engineering solution(s) to hack around that architecture problem. > is our primary concern control plane churn in the form of memory > bandwidth or memory size? I've gotten an oral answer of "both", Of course it is both, since the underlying problem is evidenced by simple growth. You get churn because of growth in routing announcements (since there are more prefixes to announce) and in memory bandwidth because you've got to drag more prefixes out of the RIB and memory size because there are more prefixes to store. The engineering hack (as argued by some) is to throw more/faster/ better hardware at the problem and hope we don't run into the laws of physics. I personally think physics is going to win in the end. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 15:17: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 1HUSk7-0007jK-QE; Thu, 22 Mar 2007 15:14:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUSk6-0007ZS-Ce for ram@iab.org; Thu, 22 Mar 2007 15:14:34 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUSk2-0008F9-03 for ram@iab.org; Thu, 22 Mar 2007 15:14:34 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 82F4A872C0; Thu, 22 Mar 2007 15:14:29 -0400 (EDT) To: int-area@ietf.org, ram@iab.org Subject: Re: [Int-area] Re: [RAM] Please be more specific about the problem Message-Id: <20070322191429.82F4A872C0@mercury.lcs.mit.edu> Date: Thu, 22 Mar 2007 15:14:29 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: jnc@mercury.lcs.mit.edu 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: Danny McPherson > I suspect one way to look at this is to ask what's going to break first? According to what I'm hearing, it's ISP's wallets. We can certainly build boxes with bigger/faster memory arrays (we need faster if stabilization time is to be constant in real-time, while the table itself keeps getting bigger), but it will cost a small boat of money for a core router with mega-tables, and the ISP business these days is not exactly one in which one makes a lot of money (witness the significant number of ISP's who have had financial difficulties...) In other words, it doesn't do much good to be able to big mega-big-fast core routers, if none of the supposed customers have the money to be able to buy/deploy them. Reminds me of that old line: "An engineer is a person who can do for a dime what any fool can do for a dollar." Translation: Throwing expensive hardware at the problem is not the answer. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 15:29: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 1HUSxH-0004qZ-RD; Thu, 22 Mar 2007 15:28:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUSxH-0004q6-3G; Thu, 22 Mar 2007 15:28:11 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUSxE-0002ha-Ov; Thu, 22 Mar 2007 15:28:11 -0400 Received: from [192.168.1.155] (tulip-inn-terminus.fwa.tiscali.cz [195.146.103.206]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l2MJRQ0m075319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Mar 2007 20:27:28 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <75E7FB2B-26F6-45DD-A7EB-3273D708938B@cisco.com> References: <218BF3BA-9B4B-4E82-8234-36BEF304A331@muada.com> <75E7FB2B-26F6-45DD-A7EB-3273D708938B@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] My remarks at the microphone Date: Thu, 22 Mar 2007 20:27:39 +0100 To: Dino Farinacci X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.9 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: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: int-area@ietf.org, 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 22-mrt-2007, at 19:02, Dino Farinacci wrote: >> As I said, BGP and DNS can both be considered to be mapping >> protocols, and they both have some aspects that are desirable and >> some aspects that are problematic. > After this week, I have concluded that both BGP and DNS *should > not* be considered. However, we could model something new off of > BGP and DNS. That is, a pull versus push model or a combination of > both. Indeed. >> BGP on the other hand floods everything but has serious scaling >> issues and suffers from the problem that local optimizations >> introduce global state. > BGP does not flood everything. On eBGP peering it sends only best > paths. (iBGP does that, too.) I mean everything in the sense of all prefixes. >> What we need in a new mapping system is the scalability and >> parallelism of the DNS coupled with the immediacy of BGP, but >> where BGP distributes next hop information, the new mapping system >> should distribute "last hop" information. > What is last-hop information? In BGP, there is a "next hop" attribute that pretty much does what the name suggests, we'd expect nothing less from a routing protocol. However, in an id/loc (or loc/loc) mapping system, we're not coming dealing with the next hop the packet is sent to, but rather, the place where it can be decapsulated, which can be considered the "last hop" although that's probably not 100% accurate. The intermediate hops don't interest us here, either we assume that if a locator address is present in the mapping database it's reachable (and we flood unreachability information) or we put in an additional protocol that checks whether the decapsulation box is reachable. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 17:08: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 1HUUSz-00058z-Om; Thu, 22 Mar 2007 17:05:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUUSx-0004zE-T4 for ram@iab.org; Thu, 22 Mar 2007 17:04:59 -0400 Received: from web58714.mail.re1.yahoo.com ([66.196.100.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HUUSu-0001TY-9E for ram@iab.org; Thu, 22 Mar 2007 17:04:59 -0400 Received: (qmail 99228 invoked by uid 60001); 22 Mar 2007 21:04:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=AoNm9oFAMMiymCdzFaXR2Ad7JWO8Tt9n6FChjRzSckmJamDEPNALkwbihNRHtFz6wPGOiF5KxWAHhq7HvAcbltnqyX9YBrde0VwUhh68WGSEtl0aFFIP7LEcT4WFCTIAtiqNREC6+XR8KbclI7sLWs5PdU9Nljr++Z7/kguTEEg=; X-YMail-OSG: HShKISAVM1kfXjIVYd4qQ6caDY5p_Ut3FHS9dKMzf0bRxqqI1jpERj4L_GpBHFVi3cKCtYx5F9gmBB.9yijLuQpCdRESjFodqnyh.j4RfDD08HripvngbYTsH2HMol.lLhxLAiJEA7jVtGLrOGRR_WM._w-- Received: from [207.107.50.100] by web58714.mail.re1.yahoo.com via HTTP; Thu, 22 Mar 2007 14:04:54 PDT Date: Thu, 22 Mar 2007 14:04:54 -0700 (PDT) From: Peter Sherbin To: int-area@ietf.org, ram@iab.org, rrg@psg.com In-Reply-To: <4602AD77.6050302@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <61433.98829.qm@web58714.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [RAM] Loc / Id split 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 ietf-68/ram discussions loc/id split looks like the way people would want to pursue. Assuming id = name, we have an opportunity to set a naming structure for everything. Literally give a unique name to each and every thing we know. E.g. use ASCII for a "bee" = "62:65:65" or "01100010 01100101 01100101". Catalogs of name hierarchies exist for ages. Why do not formalize it once and for all via a standard numbering convention. Thus we will have ions of unique names. And than a few millions or billions of locators/addresses. Combination Name + Locator = IPv6 source/destination descriptor. IPv6 has enough room for names. If you think about it IPv6 designers were solving naming problem rather than the locators' one. Routing will not change other than a smaller table and removal of NAT. TE and Multihoming suddenly become non-issues. Thanks, Peter ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 18:48:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUW0T-0001hJ-2m; Thu, 22 Mar 2007 18:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUW0S-0001hC-1A for ram@iab.org; Thu, 22 Mar 2007 18:43:40 -0400 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUW0B-0005sM-9G for ram@iab.org; Thu, 22 Mar 2007 18:43:40 -0400 Received: from [10.0.1.34] (dhcp-4009.ietf68.org [130.129.64.9]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id l2MMhJYd022271 for ; Thu, 22 Mar 2007 15:43:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <454810F09B5AA04E9D78D13A5C39028A01A3DDEB@nyrofcs2ke2k01.corp.pvt> <460262BF.20305@piuha.net> <280B49D0-D7D5-4BC0-891F-87747D09BCCB@tcb.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73C8300D-6B33-4E2B-86E8-EB256C81BD5F@cs.ucla.edu> Content-Transfer-Encoding: 7bit From: Lixia Zhang Subject: Re: Workshop report Re: [RAM] Re: Impending publication:draft-iab-raws-report-01.txt Date: Thu, 22 Mar 2007 15:43:17 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Finally caught up this thread; I believe this msg by Chris is the last one on this subject line. I've fixed all the editorial comments from Pekka Savola (Thanks Pekka!) As far as I can tell, the consensus is to add to the end of abstract the following paragraph by Ross: Work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. If no further comment, this will go in. I understand that the official last-call ends on April 4th. As Jari suggested, lets focus effort on the new work now. Chris, got your suggestion on "some timeframe to bracket the work seems useful", seems to me a good suggestion both to IAB and to RRG for consideration. Lixia (with the report editor hat on) On Mar 22, 2007, at 11:15 AM, Chris L. Morrow wrote: > On Thu, 22 Mar 2007, Danny McPherson wrote: >> On Mar 22, 2007, at 5:04 AM, Jari Arkko wrote: >> >>> >>>> Not that we have a fire to fight but ARIN members are already >>>> "thinking" about proposing policy to use subnetting with PA. This >>>> would be bad as we all know, and because of this, I strongly feel >>>> it would be beneficial to hunker down and create a solution >>>> quickly AND with compitence. Debating the time frame really is >>>> neither here nor there. We just need to do it >>> >>> +1 >>> >>> The hard part is doing the solution. Lets focus more on that. > > Jari, I agree about the 'lets move forward on a solution' (whole > heartedly > actually) but my question originally was to frame 'long term' and > 'short > term' properly. > >> >> While I agree with this sentiment on one level, it concerns >> me that we're not aiming at some common end goal (even >> with accepting that it's a moving target). > > I was hoping that part of the goal included a rough timeframe :) I > think > we can noddle around on this for a very long time, some timeframe to > bracket the work seems useful. Perhaps the IAB has that in mind? or in > it's process? or the IETF does? (have a built-in TTL for work I mean) > > anyway.. forward progress, it's a good thing :) > > _______________________________________________ > 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 Thu Mar 22 20:33: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 1HUXfp-0006YJ-6I; Thu, 22 Mar 2007 20:30:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUXeE-0005bu-LE for ram@iab.org; Thu, 22 Mar 2007 20:28:50 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUXdk-0004HV-S8 for ram@iab.org; Thu, 22 Mar 2007 20:28:22 -0400 Received: by nf-out-0910.google.com with SMTP id y38so1673090nfb for ; Thu, 22 Mar 2007 17:28:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=P+1QugMcPmzayZn9xYVRZn4veh/B+/7LFGxz+e9pzjxTKYgU/vryqzw+Rgc/apb7ggCehi0eY7i/U6/UGv4ZYWrf5qSBhBrZbJOOBwQVfEm5hyFMLDosekHsnMf9uUzlmqYZpkqwijnjPiC39DCvaGMhL6Ddye9tdy4Bx/rXB9w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Af4qyREPZTPBcahZ/hWljqNX114Zdk2qK9uoGDghnAzppQFiNdp0i6WC0ZQCdrx/K9DoOIk013IrjY73itWU8fkZEJWiqyy/TAS9qY3lrNo7X2zw9svOXoVNy3lzQtpJ2LrrRt1pZQey3Vs+P9WHe/5uhXgp4phA3cMrF4RVPvE= Received: by 10.78.106.3 with SMTP id e3mr1296795huc.1174609699858; Thu, 22 Mar 2007 17:28:19 -0700 (PDT) Received: by 10.78.18.5 with HTTP; Thu, 22 Mar 2007 17:28:19 -0700 (PDT) Message-ID: <364433c70703221728i5c289516kbb87e391fe8ba09@mail.gmail.com> Date: Fri, 23 Mar 2007 01:28:19 +0100 From: "Pierre Baume" To: "Noel Chiappa" Subject: Re: [Int-area] Re: [RAM] Please be more specific about the problem In-Reply-To: <20070322191429.82F4A872C0@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070322191429.82F4A872C0@mercury.lcs.mit.edu> X-Google-Sender-Auth: dc089fe939afff05 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: int-area@ietf.org, 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 Noel, On 3/22/07, Noel Chiappa wrote: > > From: Danny McPherson > > > I suspect one way to look at this is to ask what's going to break first? > > According to what I'm hearing, it's ISP's wallets. [...] > Noel [...] Maybe. Before they get to that point, there certainly would be more filtering. More specifics would sound like a prime candidate to me, but then again, I'm not running a tier-1 network. :-} Pierre. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 22 22:33: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 1HUZX6-0004zJ-9U; Thu, 22 Mar 2007 22:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUZX4-0004lb-9w for ram@iab.org; Thu, 22 Mar 2007 22:29:34 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUZX1-0006jG-Vc for ram@iab.org; Thu, 22 Mar 2007 22:29:34 -0400 Received: from [10.0.1.79] (dhcp-4009.ietf68.org [130.129.64.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 8400D6434C; Thu, 22 Mar 2007 19:29:25 -0700 (MST) In-Reply-To: <20070322191429.82F4A872C0@mercury.lcs.mit.edu> References: <20070322191429.82F4A872C0@mercury.lcs.mit.edu> 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: Danny McPherson Subject: Re: [Int-area] Re: [RAM] Please be more specific about the problem Date: Thu, 22 Mar 2007 20:29:22 -0600 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: int-area@ietf.org, 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 Mar 22, 2007, at 1:14 PM, Noel Chiappa wrote: > > According to what I'm hearing, it's ISP's wallets. > > We can certainly build boxes with bigger/faster memory arrays (we > need faster > if stabilization time is to be constant in real-time, while the > table itself > keeps getting bigger), but it will cost a small boat of money for a > core > router with mega-tables, and the ISP business these days is not > exactly one > in which one makes a lot of money (witness the significant number > of ISP's > who have had financial difficulties...) Indeed, something I know firsthand.. > In other words, it doesn't do much good to be able to big mega-big- > fast core > routers, if none of the supposed customers have the money to be > able to > buy/deploy them. I agree with this as well, and anything in this context certainly wasn't the point of my earlier message. My point was that there are operational things that can be done today that have a dramatic impact on the scalability of today's routing system, and in particular, the service providers that field the brunt of the load. In parallel, there are things that can be done with regard to incremental improvements on routing protocol and implementation side with existing protocols to improve upon this as well. Subsequent to that, or in parallel, actually, intermediate solutions are fine, so long as a common end goal is identified, and these intermediate solutions move us closer to that end goal. Clearly, the work that Dino & co. are doing has merit. As for the end goal, I believe a fine target for the Internet area is to simply subscribe to the end to end argument. Getting there is of course the challenge, but agreement upon this fundamental end goal, and accepting that to get there with an architecture that's capable of decoupling locators and IDs, thereby helping to address the long-term concerns with network and routing system scalability, is clearly to the benefit of all those involved. Furthermore, an end to end model will get us at least as far as we are today from an applications perspective, and middlebox and similar solutions can be accommodated, so long as the end hosts themselves subscribe to such a model. > "An engineer is a person who can do for a dime what any fool can > do for a > dollar." > > Translation: Throwing expensive hardware at the problem is not the > answer. I agree completely. -danny _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 23 01:38: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 1HUcQc-0004dT-Uy; Fri, 23 Mar 2007 01:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUcQb-0004cd-BB for ram@iab.org; Fri, 23 Mar 2007 01:35:05 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUcQa-0001tm-1T for ram@iab.org; Fri, 23 Mar 2007 01:35:05 -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 05620154F3; Fri, 23 Mar 2007 06:35:02 +0100 (CET) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 23 Mar 2007 06:34:37 +0100 To: Iljitsch van Beijnum ,ram@iab.org From: JFC Morfin Subject: Re: [RAM] My remarks at the microphone In-Reply-To: <218BF3BA-9B4B-4E82-8234-36BEF304A331@muada.com> References: <218BF3BA-9B4B-4E82-8234-36BEF304A331@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070323053502.05620154F3@smtp7-g19.free.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: int-area@ietf.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 15:24 22/03/2007, Iljitsch van Beijnum wrote: >1. in hosts >2. in site border routers / middleboxes >3. in ISP networks 4. through OPES _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 23 03:29:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUeB7-00013q-87; Fri, 23 Mar 2007 03:27:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUeB5-00013i-3t for ram@iab.org; Fri, 23 Mar 2007 03:27:11 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUeB3-0006rj-Mw for ram@iab.org; Fri, 23 Mar 2007 03:27:11 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5BF7E212D16; Fri, 23 Mar 2007 09:27:06 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 05F77212C49; Fri, 23 Mar 2007 09:27:05 +0200 (EET) In-Reply-To: <4602609c.7806f8f6.7f38.6da2@mx.google.com> References: <4602609c.7806f8f6.7f38.6da2@mx.google.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68760D57-3E6E-4165-8D02-CAA3A53FBE89@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] add services to list of requirements Date: Fri, 23 Mar 2007 07:01:05 +0100 To: Gregory M. Lebovitz X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) 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 > I didn't hear stated yet: > - need ID for SERVICES, as in: > - smtp services (load balanced, globally, redundant) > - some home grown web services which actually uses MANY > different protocols to many other different service/locator pairings > - a web site I mentioned this passingly, under the bullet "delegable application level names". With suitable carved identifiers, it is indeed possible to use the same identifier space for abstract services, service instances, virtual hosts hosting those service instances, and physical hosts hosting those virtual hosts, at least. The key here is delegability; consider Dave Thaler's trust chains. You just add boxes the the left, before the identifier, and then you have to add suitable security to make each delegation/indirection step secure. With self- authenticating identifiers that is easy. One of our students considered implementing this with HIP, but I don't remember if he ever did it. In any case, it is not too hard to add to HIP, due to the self-authenticating identifiers. For the same reason, it probably could also be added to some variant of SHIM6, at least if CGAs are used. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 23 05:48: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 1HUgLF-00078K-Mq; Fri, 23 Mar 2007 05:45:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUgLE-00076F-4A for ram@iab.org; Fri, 23 Mar 2007 05:45:48 -0400 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUgLC-0006r5-RK for ram@iab.org; Fri, 23 Mar 2007 05:45:48 -0400 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id C308E53F3E6; Fri, 23 Mar 2007 04:45:41 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id 8NlhPC8m5nRz; Fri, 23 Mar 2007 04:45:36 -0500 (EST) Received: from [130.129.18.19] (dhcp-1213.ietf68.org [130.129.18.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 8C7E953E0EA; Fri, 23 Mar 2007 04:45:35 -0500 (EST) In-Reply-To: References: <218BF3BA-9B4B-4E82-8234-36BEF304A331@muada.com> <75E7FB2B-26F6-45DD-A7EB-3273D708938B@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3245BE42-FF10-401A-A2D9-0D3DE009428B@bgp.nu> Content-Transfer-Encoding: 7bit From: "John G. Scudder" Subject: Re: [RAM] My remarks at the microphone Date: Fri, 23 Mar 2007 10:45:31 +0100 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: int-area@ietf.org, 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 Mar 22, 2007, at 8:27 PM, Iljitsch van Beijnum wrote: >>> What we need in a new mapping system is the scalability and >>> parallelism of the DNS coupled with the immediacy of BGP, but >>> where BGP distributes next hop information, the new mapping >>> system should distribute "last hop" information. > >> What is last-hop information? > > In BGP, there is a "next hop" attribute that pretty much does what > the name suggests, we'd expect nothing less from a routing > protocol. However, in an id/loc (or loc/loc) mapping system, we're > not coming dealing with the next hop the packet is sent to, but > rather, the place where it can be decapsulated, which can be > considered the "last hop" although that's probably not 100% > accurate. The intermediate hops don't interest us here, either we > assume that if a locator address is present in the mapping database > it's reachable (and we flood unreachability information) or we put > in an additional protocol that checks whether the decapsulation box > is reachable. I'm not sure if it's productive to get this far down into the minutiae of BGP, but IMO the semantics of the BGP next hop (in particular, that of IBGP or multihop EBGP) are closely aligned with what you've referred to as "last hop". That is, the IBGP next hop specifies a typically distant router, and the physical next hop router has to be determined through further means (e.g., a lookup in the IGP, but also recall that for some address families the next hop is reached through some kind of tunnel -- think about VPNv4 or softwires). The only real divergence between this and what you've called a "last hop" router is that it's more difficult to determine reachability of the "last hop" a priori than it is for a regular BGP next hop, since the "last hop" will typically be in some distant AS. I don't intend to make the case one way or the other as to BGP's suitability as a mapping protocol, but did want to point out that (IMO) the "last hop" point doesn't really apply. --John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 23 05:51: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 1HUgQ7-0005J1-RP; Fri, 23 Mar 2007 05:50:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUgQ6-0005Il-Ks for ram@iab.org; Fri, 23 Mar 2007 05:50:50 -0400 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUgQ5-0008Pz-Am for ram@iab.org; Fri, 23 Mar 2007 05:50:50 -0400 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id F0FB353F3E6; Fri, 23 Mar 2007 04:50:48 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id pH+0+wSDD42e; Fri, 23 Mar 2007 04:50:43 -0500 (EST) Received: from [130.129.18.19] (dhcp-1213.ietf68.org [130.129.18.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id A475C53E0EA; Fri, 23 Mar 2007 04:50:42 -0500 (EST) In-Reply-To: References: <218BF3BA-9B4B-4E82-8234-36BEF304A331@muada.com> <75E7FB2B-26F6-45DD-A7EB-3273D708938B@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: John G. Scudder Subject: Re: [RAM] My remarks at the microphone Date: Fri, 23 Mar 2007 10:50:39 +0100 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: int-area@ietf.org, 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 [re-sending after adding myself to int-area, sorry for the duplicate to ram and individuals] On Mar 22, 2007, at 8:27 PM, Iljitsch van Beijnum wrote: >>> What we need in a new mapping system is the scalability and >>> parallelism of the DNS coupled with the immediacy of BGP, but >>> where BGP distributes next hop information, the new mapping >>> system should distribute "last hop" information. > >> What is last-hop information? > > In BGP, there is a "next hop" attribute that pretty much does what > the name suggests, we'd expect nothing less from a routing > protocol. However, in an id/loc (or loc/loc) mapping system, we're > not coming dealing with the next hop the packet is sent to, but > rather, the place where it can be decapsulated, which can be > considered the "last hop" although that's probably not 100% > accurate. The intermediate hops don't interest us here, either we > assume that if a locator address is present in the mapping database > it's reachable (and we flood unreachability information) or we put > in an additional protocol that checks whether the decapsulation box > is reachable. I'm not sure if it's productive to get this far down into the minutiae of BGP, but IMO the semantics of the BGP next hop (in particular, that of IBGP or multihop EBGP) are closely aligned with what you've referred to as "last hop". That is, the IBGP next hop specifies a typically distant router, and the physical next hop router has to be determined through further means (e.g., a lookup in the IGP, but also recall that for some address families the next hop is reached through some kind of tunnel -- think about VPNv4 or softwires). The only real divergence between this and what you've called a "last hop" router is that it's more difficult to determine reachability of the "last hop" a priori than it is for a regular BGP next hop, since the "last hop" will typically be in some distant AS. I don't intend to make the case one way or the other as to BGP's suitability as a mapping protocol, but did want to point out that (IMO) the "last hop" point doesn't really apply. --John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 23 06:21:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUgsh-0006Cs-BR; Fri, 23 Mar 2007 06:20:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUgsg-0006CW-Gy for ram@iab.org; Fri, 23 Mar 2007 06:20:22 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUgsf-0006hn-87 for ram@iab.org; Fri, 23 Mar 2007 06:20:22 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 Mar 2007 11:20:17 +0100 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 l2NAKFMg015029; Fri, 23 Mar 2007 11:20:15 +0100 Received: from elear-mac.cisco.com (ams3-vpn-dhcp4344.cisco.com [10.61.80.247]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2NAKAlZ026293; Fri, 23 Mar 2007 10:20:15 GMT Message-ID: <4603A9DD.2040504@cisco.com> Date: Fri, 23 Mar 2007 11:20:13 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] Re: [Int-area] Please be more specific about the problem References: <20070322130735.9D2E986AE9@mercury.lcs.mit.edu> <4602C211.4020902@cisco.com> <2A3B6CC7-9804-4363-BB84-59807727C15B@virtualized.org> In-Reply-To: <2A3B6CC7-9804-4363-BB84-59807727C15B@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=488; t=1174645215; x=1175509215; 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]=20Re=3A=20[Int-area]=20Please=20be=20more=20spe cific=20about=20the=20problem |Sender:=20; bh=7Z5JWqr5y266yV7XW+CnETEryZsRN14chz/0r5pm3TM=; b=rordObRPdfO/Yrl/PSuHGCHe7DsYqPAmVSOsmH9sl2WRr9QSXNj8U6Zsi6ZDevdbaQ3YAcDC FmEXxVOqjC39sNUMbRfTL+COO1/1PqNEJTeEV9JbqJtcgVL8nJCaEjiq; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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: > Of course it is both, since the underlying problem is evidenced by > simple growth. You get churn because of growth in routing > announcements (since there are more prefixes to announce) and in > memory bandwidth because you've got to drag more prefixes out of the > RIB and memory size because there are more prefixes to store. Yes, but what are the scaling properties of memory size in terms of COGS? If we don't care we have more options. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 23 07:30: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 1HUhvQ-0001JZ-Bm; Fri, 23 Mar 2007 07:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUhvP-0001JL-MG for ram@iab.org; Fri, 23 Mar 2007 07:27:15 -0400 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUhvO-0000i8-E9 for ram@iab.org; Fri, 23 Mar 2007 07:27:15 -0400 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id A28F653F3E8; Fri, 23 Mar 2007 06:27:07 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id Vt8Ra5EqQOpM; Fri, 23 Mar 2007 06:27:00 -0500 (EST) Received: from [172.23.9.18] (nat-service4.juniper.net [66.129.225.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id C31AB53E0EA; Fri, 23 Mar 2007 06:26:59 -0500 (EST) In-Reply-To: <46025A25.4080307@cisco.com> References: <46025A25.4080307@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: "John G. Scudder" Subject: Re: [RAM] Please be more specific about the problem Date: Fri, 23 Mar 2007 12:26:55 +0100 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Internet Area , 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 Mar 22, 2007, at 11:27 AM, Eliot Lear wrote: > Please provide data and analysis to support your statement. A URL > is sufficient. If we do not agree that we have enough data and > analysis, perhaps our next step should be to get the data and do > the analysis. The lack of data and analysis in this week's > presentations was extremely disturbing. If the available data is such that different reasonable people can arrive at different conclusions, what do you think the implication is? Thanks, --John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 23 17:52:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUray-0003vT-HG; Fri, 23 Mar 2007 17:46:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUraw-0003ae-FO for ram@iab.org; Fri, 23 Mar 2007 17:46:46 -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 1HUrat-0008Tl-Uw for ram@iab.org; Fri, 23 Mar 2007 17:46:46 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l2NLkQYT008207 for ; Fri, 23 Mar 2007 23:46:26 +0200 Date: Fri, 23 Mar 2007 23:46:26 +0200 (EET) From: Pekka Savola To: ram@iab.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.1/2898/Thu Mar 22 05:57:27 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=failed 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: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [RAM] Distribution of pain and gain 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 Hello all, In order for any change to be relevant from the deployment perspective, it's crucial to examine which parties are having (most) pain and what is the associated deployment benefit. 1) Big Tier1 and some Tier2 ISPs. Dense iBGP meshing, VPN routes, TE deaggregates and DFZ contribute to a large number of RIB entries (even in the order of 1-2M+ with multiple paths) and FIB entries (even in the order of ~0.5M entries). Technical solutions ("newer hardware") exist to solve this problem but deploying it would be costly as most ISP-ISP edge routers would need to be updated. FIB/RIB sizes could be possibly somewhat reduced by centralizing computation (e.g., more route-reflectors). Likewise, ISPs could employ stricter prefix-filtering (e.g., based on allocation boundaries unless explicitly agreed) and employ more locally-scoped ISP-ISP traffic engineering (e.g., agreed communities to affect lower/raise localpref, MED, NO-EXPORT community w/ more specifics) instead of balancing/adjusting traffic using e.g., deaggregation. These would make the network more difficult to operate though, and especially prefix-length restrictions would require significant maintenance. The bottom line from this perspective is that buying new routers (or trying to get the IETF to specify backwards-compatible RIB/FIB reduction mechanisms) is probably cheaper than changing the operational practices. 2) Mid-sized ISPs. These have significantly smaller number of RIB/FIB entries compared to big ISPs, and as such are mainly affected by very old hardware issues (e.g., 256K maximum prefixes). While some might find an architecturally cleaner solution preferable, the equipment will need to be replaced anyway and the solution could not be applied. It is also not clear if such a solution would support the ISP's or their customers' TE requirements. It seems likely that from operational and business continuity perspective, just upgrading equipment is the safest choice. 3) BGP-using endsites, smaller ISPs. Getting an AS number and a routable IP prefix has become easier and easier. Endsites do not feel any pain at present. Many have full BGP feeds from their transit ISPs, but outbound traffic engineering could easily be achieved with a subset of DFZ or even default routes provided that the endsites connect to ISPs which provide reachability to everywhere (e.g. Tier2-3's who acknowledge being Tier2-3s) Given that only few upstream ISPs restrict prefix deaggregation, inbound TE can easily be achieved by polluting the DFZ. The bottom line is that endsites feel no pain, and as long as transit ISPs do not have stricter filters on accepted TE usage, endsites have no interest whatsoever to change their practices. 4) Non-BGP using, possibly multihoming/connecting endsites (smaller enterprises, home users with DSL+cable, etc.). This is a segment where SHIM6-like solutions are most applicable. At the higher end of this niche (managed, but small enterprise network) there is some need for solutions which would avoid renumbering. It seems that architectural solutions here would be most applicable here, but would not be explicitly deployed even if such existed. Support would need to be bundled together with either host upgrades or moderately-priced CPEs. As a bottom line, big ISPs seem to be looking for software implementation or minor protocol enhancements to address the issues they are seeing. Architectural solutions do not solve their short/mid-term problems and even if they did, the cost of upgrading equipment is likely smaller than getting required major new protocols deployed. As soon as big ISPs *really* start to feel the pain, they'll either justify upgrades or start doing prefix etc. filtering. Before prefix/update filtering starts to become enforced by bigger ISPs, there is zero incentive for smaller ISPs and endsites to change any of their operational practices, and there is no incentive to deploy solutions in this context. There is potential area of work on non-BGP using endsites but doing anything there is not going to address FIB/RIB issues. At best this could make it more lucrative for small sites to not go for a BGP-based solution if adequate solution exists (I argue that NAT/loadbalancer boxes in v4 probably already fill this gap), i.e., limit the BGP-endsite growth curve. It will be interesting to see whether big ISPs will start to apply some prefix/update-filtering or just go for new hardware when they _really_ start feeling the pain. Maybe the architecturally best end-game solution can be achieved if big ISPs will start prefix/update-filtering :-) -- 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 Fri Mar 23 18:14: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 1HUs19-0006NJ-T6; Fri, 23 Mar 2007 18:13:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUs18-0006N9-WA for ram@iab.org; Fri, 23 Mar 2007 18:13:51 -0400 Received: from imo-m28.mx.aol.com ([64.12.137.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUs11-0005hK-Ha for ram@iab.org; Fri, 23 Mar 2007 18:13:50 -0400 Received: from HeinerHummel@aol.com by imo-m28.mx.aol.com (mail_out_v38_r7.10.) id 3.c3a.10f0de4b (42805); Fri, 23 Mar 2007 18:13:34 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Fri, 23 Mar 2007 18:13:34 EDT Subject: Re: [RAM] Distribution of pain and gain To: pekkas@netcore.fi, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf 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="===============1593063164==" Errors-To: ram-bounces@iab.org --===============1593063164== Content-Type: multipart/alternative; boundary="-----------------------------1174688014" -------------------------------1174688014 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 >From ISPs you will never get a plan how to build a lung while they know how= =20 to take in oxygen via the skin. Obviously this email favors to keep up with BGP for ever, no matter how =20 useless the worldwide UPDATE churn is. Right? I do not mind at all that short-term solutions are considered as well, e.g.= =20 inside idr. =20 Maybe the mailinglists should have a clear scope of objectives,e.g. =20 idr: BGP-based solutions RAM: LISP 1.0,...,3.x RRG: long-term only =20 Heiner =20 =20 In einer eMail vom 23.03.2007 22:50:36 Westeurop=E4ische Normalzeit schreibt= =20 pekkas@netcore.fi: Hello all, In order for any change to be relevant from the deployment =20 perspective, it's crucial to examine which parties are having (most) =20 pain and what is the associated deployment benefit. 1) Big Tier1 and some Tier2 ISPs. Dense iBGP meshing, VPN routes, TE deaggregates and DFZ contribute to a large number of RIB entries (even in the order of 1-2M+ with multiple paths) and FIB entries (even in the order of ~0.5M entries). Technical solutions ("newer hardware") exist to solve this problem but deploying it would be costly as most ISP-ISP edge routers would need to be updated. FIB/RIB sizes could be possibly somewhat reduced by centralizing computation (e.g., more route-reflectors). Likewise, ISPs could employ stricter prefix-filtering (e.g., based on allocation boundaries unless explicitly agreed) and employ more locally-scoped ISP-ISP traffic engineering (e.g., agreed communities to affect lower/raise localpref, MED, NO-EXPORT community w/ more specifics) instead of balancing/adjusting traffic using e.g., deaggregation. These would make the network more difficult to operate though, and especially prefix-length restrictions would require significant maintenance. The bottom line from this perspective is that buying new routers (or trying to get the IETF to specify backwards-compatible RIB/FIB reduction mechanisms) is probably cheaper than changing the operational practices. 2) Mid-sized ISPs. These have significantly smaller number of RIB/FIB entries compared to big ISPs, and as such are mainly affected by very old hardware issues (e.g., 256K maximum prefixes). While some might find an architecturally cleaner solution preferable, the equipment will need to be replaced anyway and the solution could not be applied. It is also not clear if such a solution would support the ISP's or their customers' TE requirements. It seems likely that from operational and business continuity perspective, just upgrading equipment is the safest choice. 3) BGP-using endsites, smaller ISPs. Getting an AS number and a routable IP prefix has become easier and easier. Endsites do not feel any pain at present. Many have full BGP feeds from their transit ISPs, but outbound traffic engineering could easily be achieved with a subset of DFZ or even default routes provided that the endsites connect to ISPs which provide reachability to everywhere (e.g. Tier2-3's who acknowledge being Tier2-3s) Given that only few upstream ISPs restrict prefix deaggregation, inbound TE can easily be achieved by polluting the DFZ. The bottom line is that endsites feel no pain, and as long as transit ISPs do not have stricter filters on accepted TE usage, endsites have no interest whatsoever to change their practices. 4) Non-BGP using, possibly multihoming/connecting endsites (smaller enterprises, home users with DSL+cable, etc.). This is a segment where SHIM6-like solutions are most applicable. At the higher end of this niche (managed, but small enterprise network) there is some need for solutions which would avoid renumbering. It seems that architectural solutions here would be most applicable here, but would not be explicitly deployed even if such existed. Support would need to be bundled together with either host upgrades or moderately-priced CPEs. As a bottom line, big ISPs seem to be looking for software=20 implementation or minor protocol enhancements to address the issues=20 they are seeing. Architectural solutions do not solve their=20 short/mid-term problems and even if they did, the cost of upgrading=20 equipment is likely smaller than getting required major new protocols=20 deployed. As soon as big ISPs *really* start to feel the pain,=20 they'll either justify upgrades or start doing prefix etc. filtering. Before prefix/update filtering starts to become enforced by bigger=20 ISPs, there is zero incentive for smaller ISPs and endsites to change=20 any of their operational practices, and there is no incentive to =20 deploy solutions in this context. There is potential area of work on non-BGP using endsites but doing=20 anything there is not going to address FIB/RIB issues. At best this=20 could make it more lucrative for small sites to not go for a BGP-based=20 solution if adequate solution exists (I argue that NAT/loadbalancer=20 boxes in v4 probably already fill this gap), i.e., limit the=20 BGP-endsite growth curve. It will be interesting to see whether big ISPs will start to apply=20 some prefix/update-filtering or just go for new hardware when they=20 _really_ start feeling the pain. Maybe the architecturally best end-game solution can be achieved if=20 big ISPs will start prefix/update-filtering :-) --=20 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 =20 -------------------------------1174688014 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
From ISPs you will never get a plan how to build a lung while they= =20 know how to take in oxygen via the skin.
Obviously this email favors to keep up with BGP for ever, no matter how= =20 useless the worldwide UPDATE churn is. Right?
I do not mind at all that short-term solutions are considered as w= ell,=20 e.g. inside idr.
 
Maybe the mailinglists should have a clear scope of objectives,e.g.
 
idr: BGP-based solutions
RAM: LISP 1.0,...,3.x
RRG: long-term only
 
Heiner
 
 
In einer eMail vom 23.03.2007 22:50:36 Westeurop=E4ische Normalzeit sch= reibt=20 pekkas@netcore.fi:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>Hello=20 all,

In order for any change to be relevant from the deployment=20
perspective, it's crucial to examine which parties are having (most)=20
pain and what is the associated deployment benefit.

  1) B= ig=20 Tier1 and some Tier2 ISPs.  Dense iBGP meshing, VPN routes, TE
&nb= sp;=20    deaggregates and DFZ contribute to a large number of RIB=20 entries
     (even in the order of 1-2M+ with multiple=20 paths) and FIB entries
     (even in the order of ~0.5M=20 entries).

     Technical solutions ("newer hardware"= )=20 exist to solve this problem
     but deploying it would=20= be=20 costly as most ISP-ISP edge routers
     would need to b= e=20 updated.

     FIB/RIB sizes could be possibly somewh= at=20 reduced by centralizing
     computation (e.g., more=20 route-reflectors).  Likewise, ISPs could
     emplo= y=20 stricter prefix-filtering (e.g., based on allocation
    = ;=20 boundaries unless explicitly agreed) and employ more
    = ;=20 locally-scoped ISP-ISP traffic engineering (e.g., agreed
 =20    communities to affect lower/raise localpref, MED,=20 NO-EXPORT
     community w/ more specifics) instead of=20 balancing/adjusting
     traffic using e.g.,=20 deaggregation.

     These would make the network mor= e=20 difficult to operate though, and
     especially=20 prefix-length restrictions would require significant
    = ;=20 maintenance.

     The bottom line from this perspect= ive=20 is that buying new routers
     (or trying to get the IE= TF=20 to specify backwards-compatible RIB/FIB
     reduction=20 mechanisms) is probably cheaper than changing the
    =20 operational practices.

  2) Mid-sized ISPs.  These have=20 significantly smaller number of
     RIB/FIB entries=20 compared to big ISPs, and as such are mainly
     affect= ed=20 by very old hardware issues (e.g., 256K maximum
    =20 prefixes).

     While some might find an architectur= ally=20 cleaner solution
     preferable, the equipment will nee= d to=20 be replaced anyway and the
     solution could not be=20 applied.  It is also not clear if such a
     solut= ion=20 would support the ISP's or their customers' TE
    =20 requirements.

     It seems likely that from operati= onal=20 and business continuity
     perspective, just upgrading= =20 equipment is the safest choice.

  3) BGP-using endsites, small= er=20 ISPs.  Getting an AS number and a
     routable IP=20 prefix has become easier and easier.  Endsites do not
 =20    feel any pain at present.  Many have full BGP feeds from= =20 their
     transit ISPs, but outbound traffic engineerin= g=20 could easily be
     achieved with a subset of DFZ or ev= en=20 default routes provided
     that the endsites connect t= o=20 ISPs which provide reachability to
     everywhere (e.g.= =20 Tier2-3's who acknowledge being Tier2-3s)

     Given= =20 that only few upstream ISPs restrict prefix deaggregation,
 =20    inbound TE can easily be achieved by polluting the=20 DFZ.

     The bottom line is that endsites feel no p= ain,=20 and as long as
     transit ISPs do not have stricter=20 filters on accepted TE usage,
     endsites have no inte= rest=20 whatsoever to change their practices.

  4) Non-BGP using, poss= ibly=20 multihoming/connecting endsites (smaller
     enterprise= s,=20 home users with DSL+cable, etc.).  This is a segment
 =20    where SHIM6-like solutions are most applicable.  At the=20 higher end
     of this niche (managed, but small enterp= rise=20 network) there is
     some need for solutions which wou= ld=20 avoid renumbering.

     It seems that architectural=20 solutions here would be most
     applicable here, but w= ould=20 not be explicitly deployed even
     if such existed.&nb= sp;=20 Support would need to be bundled together with
     eith= er=20 host upgrades or moderately-priced CPEs.

As a bottom line, big ISPs= =20 seem to be looking for software
implementation or minor protocol=20 enhancements to address the issues
they are seeing.  Architectura= l=20 solutions do not solve their
short/mid-term problems and even if they=20= did,=20 the cost of upgrading
equipment is likely smaller than getting require= d=20 major new protocols
deployed.  As soon as big ISPs *really* start= to=20 feel the pain,
they'll either justify upgrades or start doing prefix e= tc.=20 filtering.

Before prefix/update filtering starts to become enforced= by=20 bigger
ISPs, there is zero incentive for smaller ISPs and endsites to=20 change
any of their operational practices, and there is no incentive t= o=20
deploy solutions in this context.

There is potential area of wo= rk=20 on non-BGP using endsites but doing
anything there is not going to add= ress=20 FIB/RIB issues.  At best this
could make it more lucrative for sm= all=20 sites to not go for a BGP-based
solution if adequate solution exists (= I=20 argue that NAT/loadbalancer
boxes in v4 probably already fill this gap= ),=20 i.e., limit the
BGP-endsite growth curve.

It will be interestin= g to=20 see whether big ISPs will start to apply
some prefix/update-filtering=20= or=20 just go for new hardware when they
_really_ start feeling the=20 pain.

Maybe the architecturally best end-game solution can be achie= ved=20 if
big ISPs will start prefix/update-filtering :-)

--
Pekka= =20 Savola                 "You e= ach=20 name yourselves king, yet the
Netcore Oy        &nb= sp;=20           kingdom bleeds."
Systems. Networks.=20 Security. -- George R.R. Martin: A Clash of=20 Kings

_______________________________________________
RAM mailin= g=20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 
 -------------------------------1174688014-- --===============1593063164== 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 --===============1593063164==-- From ram-bounces@iab.org Sun Mar 25 00:44: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 1HVKVM-00084u-CM; Sun, 25 Mar 2007 00:38:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVKVJ-0007uG-QC for ram@iab.org; Sun, 25 Mar 2007 00:38:53 -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 1HVKTA-0003ka-HT for ram@iab.org; Sun, 25 Mar 2007 00:36:46 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2P4aMI1013922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 24 Mar 2007 23:36:26 -0500 (CDT) 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 l2P4aMMQ010361; Sat, 24 Mar 2007 23:36:22 -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 l2P4aLr5010352; Sat, 24 Mar 2007 23:36:21 -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); Sat, 24 Mar 2007 21:36:21 -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: Sat, 24 Mar 2007 21:36:20 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774817@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request to advance RFC4214 to Proposed Standard Thread-Index: AcdulyL8BNQ/ciFJSrKuhIOqlJnA3g== From: "Templin, Fred L" To: X-OriginalArrivalTime: 25 Mar 2007 04:36:21.0479 (UTC) FILETIME=[234E2770:01C76E97] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ram@iab.org Subject: [RAM] Request to advance RFC4214 to Proposed Standard 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 RFC Editor, This is a request to advance RFC4214 to Proposed Standard, since multiple and widely-deployed implementations exist. See: http://isatap.com Fred L. Templin fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 25 01:09: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 1HVKxu-0003WV-1a; Sun, 25 Mar 2007 01:08:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVKxs-0003W8-3U for ram@iab.org; Sun, 25 Mar 2007 01:08:24 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HVKxn-0005Id-OP for ram@iab.org; Sun, 25 Mar 2007 01:08:24 -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 l2P58Cnj019205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 25 Mar 2007 00:08:12 -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 l2P56RfL014358; Sat, 24 Mar 2007 22:06:27 -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 l2P56RYl014352; Sat, 24 Mar 2007 22:06:27 -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); Sat, 24 Mar 2007 22:06:27 -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] Request to advance RFC4214 to Proposed Standard Date: Sat, 24 Mar 2007 22:06:26 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774818@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774817@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Request to advance RFC4214 to Proposed Standard Thread-Index: AcdulyL8BNQ/ciFJSrKuhIOqlJnA3gAA1VJg References: <39C363776A4E8C4A94691D2BD9D1C9A101774817@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: X-OriginalArrivalTime: 25 Mar 2007 05:06:27.0267 (UTC) FILETIME=[57A38930:01C76E9B] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Purusant to my previous message, I would like to specifically ask that Mark Townsley tender this request as AD sponsor per RFC3932 (BCP92). Also, please note that there are multiple interoperable and widely-deployed implementations. Fred L. Templin fred.l.templin@boeing.com=20 > -----Original Message----- > From: Templin, Fred L=20 > Sent: Saturday, March 24, 2007 9:36 PM > To: rfc-editor@rfc-editor.org > Cc: ram@iab.org > Subject: [RAM] Request to advance RFC4214 to Proposed Standard >=20 > RFC Editor, >=20 > This is a request to advance RFC4214 to Proposed Standard, since > multiple and widely-deployed implementations exist. See: >=20 > http://isatap.com >=20 > Fred L. Templin > fred.l.templin@boeing.com >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 25 02:37: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 1HVMHZ-0005ri-HQ; Sun, 25 Mar 2007 02:32:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVMHX-0005rH-PL for ram@iab.org; Sun, 25 Mar 2007 02:32:47 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVMHW-0002C1-AO for ram@iab.org; Sun, 25 Mar 2007 02:32:47 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8B9C4198690; Sun, 25 Mar 2007 09:32:30 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4248E19867C; Sun, 25 Mar 2007 09:32:30 +0300 (EEST) Message-ID: <4606177E.9070405@piuha.net> Date: Sun, 25 Mar 2007 09:32:30 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [RAM] Request to advance RFC4214 to Proposed Standard References: <39C363776A4E8C4A94691D2BD9D1C9A101774817@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A101774818@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774818@XCH-NW-7V2.nw.nos.boeing.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, rfc-editor@rfc-editor.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 Fred, Just FYI -- requests to put something on the standards track go to the ADs, not the RFC Editor. For more information, see http://www.ietf.org/IESG/content/ions/ion-ad-sponsoring.html In any case, since you are copying the RAM list I presume that you think this would work as a solution to routing scalability? We do indeed have a number of solutions in the lets-cross-the- internet-by-tunneling space :-) and I too often wonder if a new tool is going to be very different from the old ones. I would appreciate some additional thoughts however on why you believe this works for routing scalability, what its properties would be, how you would deploy it, etc. Jari Templin, Fred L kirjoitti: > Purusant to my previous message, I would like to specifically > ask that Mark Townsley tender this request as AD sponsor per > RFC3932 (BCP92). Also, please note that there are multiple > interoperable and widely-deployed implementations. > > Fred L. Templin > fred.l.templin@boeing.com > > >> -----Original Message----- >> From: Templin, Fred L >> Sent: Saturday, March 24, 2007 9:36 PM >> To: rfc-editor@rfc-editor.org >> Cc: ram@iab.org >> Subject: [RAM] Request to advance RFC4214 to Proposed Standard >> >> RFC Editor, >> >> This is a request to advance RFC4214 to Proposed Standard, since >> multiple and widely-deployed implementations exist. See: >> >> http://isatap.com >> >> Fred L. Templin >> fred.l.templin@boeing.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 > > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 25 04: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 1HVOF6-0004qi-O6; Sun, 25 Mar 2007 04:38:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVOF4-0004nT-Sh for ram@iab.org; Sun, 25 Mar 2007 04:38:22 -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 1HVOF1-0000Dj-BG for ram@iab.org; Sun, 25 Mar 2007 04:38:22 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2P8c01w023242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 25 Mar 2007 01:38:01 -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 l2P8bxbH010324; Sun, 25 Mar 2007 03:37:59 -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 l2P8bxgK010310; Sun, 25 Mar 2007 03:37:59 -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); Sun, 25 Mar 2007 01:37:59 -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] Request to advance RFC4214 to Proposed Standard Date: Sun, 25 Mar 2007 01:37:58 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774819@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4606177E.9070405@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Request to advance RFC4214 to Proposed Standard Thread-Index: Acdup16lrLNID8ijSTe3joWN4V+6ZwADP60g References: <39C363776A4E8C4A94691D2BD9D1C9A101774817@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A101774818@XCH-NW-7V2.nw.nos.boeing.com> <4606177E.9070405@piuha.net> From: "Templin, Fred L" To: "Jari Arkko" X-OriginalArrivalTime: 25 Mar 2007 08:37:59.0305 (UTC) FILETIME=[E4AED790:01C76EB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ram@iab.org, rfc-editor@rfc-editor.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, Yes, I would appreciate the opportunity to talk openly which has really not been the case for the many years I have been saddled with this heavy burden. I have really no doubt that this mechanism is the "missing link" that would allow for a set of integrated tools to span the Internet end-to-end and allow for virutally limitless scaling while reducing core routing table churn and growth to sub-linear levels. Given the proper mapping function and tunnel endpoint mobility tools, it would also give global mobility management and multihoming as natural consequences of the architecture. Now, think about how cool all of this sounds - but, then stop and think about the social ramifications. How would it be, for example, if anyone on the Internet could connect to anyone else over encrypted tunnels end-to-end with no opportunity for the network to block harmful communications. The network could of course throw up road blocks, but the endpoints could simply pop up somewhere else and continue their covert and possibly ill-intended communications. In short, the endpoints could simply route around any network problem spots and keep on talking unimpeded and undetected - even if what they were talking about was planning the next major terrorist attack. This would be Internet transparency taken to the ultimate level, but one really does have to stop and ask whether the world is ready for this? Would it be utopia or anarchy - I'm really hoping that someone out there could answer that for me. Until that time, I am suspending my request for standards-track consideration. Folks have been pretty shy about talking to me for the many years I have been saddled with this. Is there anything anyone out there would like to say now? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Saturday, March 24, 2007 11:33 PM > To: Templin, Fred L > Cc: rfc-editor@rfc-editor.org; ram@iab.org; W. Mark Townsley > Subject: Re: [RAM] Request to advance RFC4214 to Proposed Standard >=20 > Fred, >=20 > Just FYI -- requests to put something on the standards track > go to the ADs, not the RFC Editor. For more information, see > http://www.ietf.org/IESG/content/ions/ion-ad-sponsoring.html >=20 > In any case, since you are copying the RAM list I presume that > you think this would work as a solution to routing scalability? > We do indeed have a number of solutions in the lets-cross-the- > internet-by-tunneling space :-) and I too often wonder if a new > tool is going to be very different from the old ones. I would > appreciate some additional thoughts however on why you > believe this works for routing scalability, what its properties > would be, how you would deploy it, etc. >=20 > Jari >=20 > Templin, Fred L kirjoitti: > > Purusant to my previous message, I would like to specifically > > ask that Mark Townsley tender this request as AD sponsor per > > RFC3932 (BCP92). Also, please note that there are multiple > > interoperable and widely-deployed implementations. > > > > Fred L. Templin > > fred.l.templin@boeing.com=20 > > > > =20 > >> -----Original Message----- > >> From: Templin, Fred L=20 > >> Sent: Saturday, March 24, 2007 9:36 PM > >> To: rfc-editor@rfc-editor.org > >> Cc: ram@iab.org > >> Subject: [RAM] Request to advance RFC4214 to Proposed Standard > >> > >> RFC Editor, > >> > >> This is a request to advance RFC4214 to Proposed Standard, since > >> multiple and widely-deployed implementations exist. See: > >> > >> http://isatap.com > >> > >> Fred L. Templin > >> fred.l.templin@boeing.com > >> > >> _______________________________________________ > >> RAM mailing list > >> RAM@iab.org > >> https://www1.ietf.org/mailman/listinfo/ram > >> > >> =20 > > > > _______________________________________________ > > RAM mailing list > > RAM@iab.org > > https://www1.ietf.org/mailman/listinfo/ram > > > > > > =20 >=20 >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 25 05:48:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVPGN-0004sf-Tl; Sun, 25 Mar 2007 05:43:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVPGN-0004rZ-6B for ram@iab.org; Sun, 25 Mar 2007 05:43:47 -0400 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVPGL-0000US-QV for ram@iab.org; Sun, 25 Mar 2007 05:43:47 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l2P9hjnq119230 for ; Sun, 25 Mar 2007 09:43:45 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l2P9hijS2490602 for ; Sun, 25 Mar 2007 10:43:44 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l2P9hiOZ007899 for ; Sun, 25 Mar 2007 10:43:44 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l2P9hihn007894; Sun, 25 Mar 2007 10:43:44 +0100 Received: from [9.145.249.166] (chv03978.de.ibm.com [9.145.249.166]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA269036; Sun, 25 Mar 2007 11:43:42 +0200 Message-ID: <4606444E.1030409@zurich.ibm.com> Date: Sun, 25 Mar 2007 11:43:42 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [RAM] Request to advance RFC4214 to Proposed Standard References: <39C363776A4E8C4A94691D2BD9D1C9A101774817@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A101774818@XCH-NW-7V2.nw.nos.boeing.com> <4606177E.9070405@piuha.net> In-Reply-To: <4606177E.9070405@piuha.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "Templin, Fred L" , rfc-editor@rfc-editor.org, 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, Speaking as a long time participant in ngtrans/v6ops, I believe this request should only be addressed via v6ops, which, if I recall correctly, has as its established consensus to progress no more IPv6 coexistence techniques. I'm not saying that consensus can't be changed, but until it is, I'd be against AD sponsoring of this request (without any comment on the merits of this or other proposed additional coexistence techniques). Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 25 05:57:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVPSL-0003XA-QD; Sun, 25 Mar 2007 05:56:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVPSK-0003WF-JL for ram@iab.org; Sun, 25 Mar 2007 05:56:08 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVPS8-0001wU-8c for ram@iab.org; Sun, 25 Mar 2007 05:55:57 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E4855198690; Sun, 25 Mar 2007 12:55:52 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8603A198677; Sun, 25 Mar 2007 12:55:52 +0300 (EEST) Message-ID: <46064728.4000805@piuha.net> Date: Sun, 25 Mar 2007 12:55:52 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [RAM] Request to advance RFC4214 to Proposed Standard References: <39C363776A4E8C4A94691D2BD9D1C9A101774817@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A101774818@XCH-NW-7V2.nw.nos.boeing.com> <4606177E.9070405@piuha.net> <4606444E.1030409@zurich.ibm.com> In-Reply-To: <4606444E.1030409@zurich.ibm.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: 93238566e09e6e262849b4f805833007 Cc: "Templin, Fred L" , rfc-editor@rfc-editor.org, 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 Sure -- the plans and opinions of an existing WG in this space is an input to a sponsoring decision. But for now I really just wanted to know why Fred thinks its relevant for the RAM discussion. Jari Brian E Carpenter kirjoitti: > Jari, > > Speaking as a long time participant in ngtrans/v6ops, > I believe this request should only be addressed via v6ops, > which, if I recall correctly, has as its established > consensus to progress no more IPv6 coexistence techniques. > > I'm not saying that consensus can't be changed, but until > it is, I'd be against AD sponsoring of this request > (without any comment on the merits of this or other > proposed additional coexistence techniques). > > Brian > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 25 17:32:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVaGU-0006FI-4O; Sun, 25 Mar 2007 17:28:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVaGS-0006FC-CY for ram@iab.org; Sun, 25 Mar 2007 17:28:36 -0400 Received: from web58704.mail.re1.yahoo.com ([66.196.100.126]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HVaGR-0006QU-40 for ram@iab.org; Sun, 25 Mar 2007 17:28:36 -0400 Received: (qmail 95635 invoked by uid 60001); 25 Mar 2007 21:28:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nsPzV04rwOvJgpO+pIcNpvrUCal9/zp1Jjbf+qU2oydp/vXXiIwP6Mj24/NUr0QTQHeNbrRDupmF9P14c8Azmg5Il3HlwUtI+nAChY8xHt6Xi8xuTy1Lrlc+tUfHOpyqkkQRjw9bAoRXEgpMYFNYkEjj5tVPJOSkR1MkkEazXss= ; Message-ID: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> X-YMail-OSG: DzEKvBUVM1m7HgKrFygOTYXVBF_FtjlqGjfnsRe6addp.OHLd1xbhOpFwEzovUougyJnEsQ.KlVdg3M7ABAkDyOr3ffEHJdNkOD2FblkGASt8LzJZr2atN3QcJQn4hyHUswDDGJg5ZtnDEXWsAyqMm7PPA-- Received: from [74.111.124.141] by web58704.mail.re1.yahoo.com via HTTP; Sun, 25 Mar 2007 14:28:32 PDT Date: Sun, 25 Mar 2007 14:28:32 -0700 (PDT) From: Peter Sherbin Subject: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) To: ram@iab.org In-Reply-To: <46064728.4000805@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 believe this very good draft is still a subject to comments and here it goes: General 1. Both EID and RLOC remain (IP) addresses of dual nature: locator & identifier. Hence actually there is no Locator/ID separation. End User 1. Depends on ISP for RLOCs, the entire notion of PI is negated 2. Extra overhead ISP and End User 1. Have to introduce 2 more sets of routers: ITP / ETP, which is an extra cost We may want to continue looking for a clear split between locator and ID, where locator describes topo location only, while ID uniquely names the object with no reference to its location. 128-bit IPv6 has enough(?) room to combine both in one source/destination descriptor. Thanks, Peter ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Mar 25 18:50: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 1HVbS5-00074M-8c; Sun, 25 Mar 2007 18:44:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVbS4-00074H-29 for ram@iab.org; Sun, 25 Mar 2007 18:44:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVbS2-0005rK-NF for ram@iab.org; Sun, 25 Mar 2007 18:44:40 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Mar 2007 15:44:38 -0700 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 l2PMibQh002904; Sun, 25 Mar 2007 15:44:37 -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 l2PMibZT016068; Sun, 25 Mar 2007 22:44:37 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Mar 2007 15:44:37 -0700 Received: from [192.168.0.4] ([10.21.88.67]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Mar 2007 15:44:37 -0700 In-Reply-To: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sun, 25 Mar 2007 15:44:37 -0700 To: Peter Sherbin X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 25 Mar 2007 22:44:37.0246 (UTC) FILETIME=[2A9D81E0:01C76F2F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3234; t=1174862677; x=1175726677; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=2qHoBJ2Mh22Nlg1oCgkoEKauE6z1R8IeoOzcw6+MzL4=; b=BBbv9uFlQ0qI4wcdSTF5umQ6SzP+29UapcNSwq7p6m0hxkjvquBjLQx7xvvguvMWzSNoMwUi HIYGFoZ5Ui1ob9rUzmh8fmPIeQTSHZkfnU0yz6gPPc4s3WAdlVw8ro6JaXUnjk6tnZLsyHqlch Wq9GoOeaPHvcg+agxE/AePcwY=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 believe this very good draft is still a subject to comments and > here it goes: Thanks for our comments. And they are certainly not coming too late. > General > 1. Both EID and RLOC remain (IP) addresses of dual nature: locator > & identifier. > Hence actually there is no Locator/ID separation. There is a separation but at the network level and not the stack level. Lixia, over last week used the term "multi-level addresses" which I think is the case for LISP based EID and Locator terms. That is, the 'address' has scope depending where the ITR and ETR are located in the source and destination site, respectively. So, if your ITR/ETR are on the first/last-hop routers, then the inner "ID addresses" are used simply used as link-local (and as connection IDs for the transport layer). If your ITR/ETR are at the CE edges of site, then the scope of the "ID address" is used throughout the site. But we can say after a packet is tunneled, that the only addresses in the outer header are certainly "Locator addresses". And are the ones we want to aggregate-optimize in the PE and P routers in the core. We will make it more clear in the next draft that this separation is network-based and has scope. > > End User > 1. Depends on ISP for RLOCs, the entire notion of PI is negated Yes, well we all depend on ISP address block allocation or else we can't send packet globally. If you are a site, not attached to the Internet, you can use RFC 1918 addresses, as you do today, to be used as both EIDs and Locators within your site scope. If you need mobility, you can deploy a LISP ITR and ETR inside of your site, and have Locator reachability inside your "site core". But I believe most sites won't need to do this. And that is goodness, because you can run your network the way you do today, even in the new world of separation (or in a "jack-up world"). > 2. Extra overhead Well yes, the cost of tunneling to get redirection is paid in terms of additional header bytes. TANSTAFL. > > ISP and End User > 1. Have to introduce 2 more sets of routers: ITP / ETP, which is an > extra cost They are not new routers, they are existing routers with new functionality. And as a vendor, I am trying to not require hardware changes to deploy the functionality. You will need a new software upgrade for the ITR/ETR. Let's see, in practice, if this turns out to be true. > We may want to continue looking for a clear split between locator > and ID, where > locator describes topo location only, while ID uniquely names the > object with no > reference to its location. 128-bit IPv6 has enough(?) room to > combine both in one > source/destination descriptor. Well, what we want to do is get site's to have ingress packet traffic engineering, get better aggregation in both PE and P routers in the core, and to allow ISPs to reroute traffic through other ISPs (ISP- based TE). We can do this with this proposal. These are the requirements and goals we would like to focus on. If, at the same time, we get session survivability at any granularity, it is a bonus. Thanks again, Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 26 05: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 1HVluk-0005X6-Ca; Mon, 26 Mar 2007 05:54:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVlui-0005Wg-IM for ram@iab.org; Mon, 26 Mar 2007 05:54:56 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVluE-0000wW-FL for ram@iab.org; Mon, 26 Mar 2007 05:54:28 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D6CD1174639; Mon, 26 Mar 2007 11:53:25 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp01.uc3m.es (Postfix) with ESMTP id 037B61745E1; Mon, 26 Mar 2007 11:50:48 +0200 (CEST) In-Reply-To: <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Mon, 26 Mar 2007 11:53:09 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 El 26/03/2007, a las 0:44, Dino Farinacci escribi=F3: >> >> ISP and End User >> 1. Have to introduce 2 more sets of routers: ITP / ETP, which is an=20= >> extra cost > > They are not new routers, they are existing routers with new=20 > functionality. And as a vendor, I am trying to not require hardware=20 > changes to deploy the functionality. You will need a new software=20 > upgrade for the ITR/ETR. Let's see, in practice, if this turns out to=20= > be true. > I think there is much more than that. If you want to perform the TE functionalities that have been described=20= in the LISP draft, you need to make the information about the multiple=20= locators available for an identifier to the ISP. Such information is=20 not available in the packet. So in order to allow the intermediate ISP=20= to acutally be able to reroute packet to altenrative locators=20 associated to the identifier contained in the inner header of the=20 packet, you must let the intermediate ISP discover the alternative=20 locator information. I am not sure how you are planning to do this, but=20= afict it will need much more infrastrucutre that what currently is=20 described in the draft. am i missing something? regards, marcelo >> We may want to continue looking for a clear split between locator and=20= >> ID, where >> locator describes topo location only, while ID uniquely names the=20 >> object with no >> reference to its location. 128-bit IPv6 has enough(?) room to combine=20= >> both in one >> source/destination descriptor. > > Well, what we want to do is get site's to have ingress packet traffic=20= > engineering, get better aggregation in both PE and P routers in the=20 > core, and to allow ISPs to reroute traffic through other ISPs=20 > (ISP-based TE). We can do this with this proposal. > > These are the requirements and goals we would like to focus on. If, at=20= > the same time, we get session survivability at any granularity, it is=20= > a bonus. > > Thanks again, > Dino > > _______________________________________________ > 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 Mar 26 10:44: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 1HVqQ5-0002cc-Rq; Mon, 26 Mar 2007 10:43:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVqPD-0001kL-F1 for ram@iab.org; Mon, 26 Mar 2007 10:42:43 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVqK3-0000zH-CM for ram@iab.org; Mon, 26 Mar 2007 10:37:29 -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 A32C215668; Mon, 26 Mar 2007 16:37:22 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Mar 2007 16:20:32 +0200 To: marcelo bagnulo braun , Dino Farinacci From: JFC Morfin Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) In-Reply-To: <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Message-Id: <20070326143722.A32C215668@smtp7-g19.free.fr> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 Marcelo, I strongly oppose to that. For three major reasons: 1) the internal packet may not be a TCP/IP packet (or a crypted=20 TCP/IP packet). This is why LISP is adequate to support=20 multitechnology systems. 2) LISP permits the user to build and force his own routing strategy.=20 And to go through secure nodes (along his own criteria). 3) depending on the final destination or on the content the ISP could=20 apply its own multi-tier strategy. This is why I tink the re-EIN concept should be reviewed together=20 with multi-level addressing and revived NIMROD topology report -=20 including information for LISP (and may be an addition to the DNS to=20 indicate the real nature of a given IP). jfc At 11:53 26/03/2007, marcelo bagnulo braun wrote: >El 26/03/2007, a las 0:44, Dino Farinacci escribi=F3: >>> >>>ISP and End User >>>1. Have to introduce 2 more sets of routers: ITP / ETP, which is=20 >>>an extra cost >> >>They are not new routers, they are existing routers with new=20 >>functionality. And as a vendor, I am trying to not require hardware=20 >>changes to deploy the functionality. You will need a new software=20 >>upgrade for the ITR/ETR. Let's see, in practice, if this turns out to b= e true. > >I think there is much more than that. >If you want to perform the TE functionalities that have been=20 >described in the LISP draft, you need to make the information about=20 >the multiple locators available for an identifier to the ISP. Such=20 >information is not available in the packet. So in order to allow the=20 >intermediate ISP to acutally be able to reroute packet to=20 >altenrative locators associated to the identifier contained in the=20 >inner header of the packet, you must let the intermediate ISP=20 >discover the alternative locator information. I am not sure how you=20 >are planning to do this, but afict it will need much more=20 >infrastrucutre that what currently is described in the draft. > >am i missing something? > > >regards, marcelo > > >>>We may want to continue looking for a clear split between locator=20 >>>and ID, where >>>locator describes topo location only, while ID uniquely names the=20 >>>object with no >>>reference to its location. 128-bit IPv6 has enough(?) room to=20 >>>combine both in one >>>source/destination descriptor. >> >>Well, what we want to do is get site's to have ingress packet=20 >>traffic engineering, get better aggregation in both PE and P=20 >>routers in the core, and to allow ISPs to reroute traffic through=20 >>other ISPs (ISP-based TE). We can do this with this proposal. >> >>These are the requirements and goals we would like to focus on. If,=20 >>at the same time, we get session survivability at any granularity,=20 >>it is a bonus. >> >>Thanks again, >>Dino >> >>_______________________________________________ >>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 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 26 10:53: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 1HVqY8-00015E-Uc; Mon, 26 Mar 2007 10:51:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVqY8-00010c-3k for ram@iab.org; Mon, 26 Mar 2007 10:51:56 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVqY5-00042i-IX for ram@iab.org; Mon, 26 Mar 2007 10:51:56 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B69D81741B0; Mon, 26 Mar 2007 16:51:51 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp01.uc3m.es (Postfix) with ESMTP id A051017432E; Mon, 26 Mar 2007 16:51:51 +0200 (CEST) In-Reply-To: <20070326143722.A32C215668@smtp7-g19.free.fr> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <20070326143722.A32C215668@smtp7-g19.free.fr> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <25677a9ed31e863414a481f1b5df5395@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Mon, 26 Mar 2007 16:54:12 +0200 To: JFC Morfin X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 El 26/03/2007, a las 16:20, JFC Morfin escribi=F3: > Marcelo, > I strongly oppose to that. i am not following you... exactly you strongly oppose to what? regards, marcelo > For three major reasons: > > 1) the internal packet may not be a TCP/IP packet (or a crypted TCP/IP=20= > packet). This is why LISP is adequate to support multitechnology=20 > systems. > 2) LISP permits the user to build and force his own routing strategy.=20= > And to go through secure nodes (along his own criteria). > 3) depending on the final destination or on the content the ISP could=20= > apply its own multi-tier strategy. > > This is why I tink the re-EIN concept should be reviewed together with=20= > multi-level addressing and revived NIMROD topology report - including=20= > information for LISP (and may be an addition to the DNS to indicate=20 > the real nature of a given IP). > jfc > > At 11:53 26/03/2007, marcelo bagnulo braun wrote: > >> El 26/03/2007, a las 0:44, Dino Farinacci escribi=F3: >>>> >>>> ISP and End User >>>> 1. Have to introduce 2 more sets of routers: ITP / ETP, which is an=20= >>>> extra cost >>> >>> They are not new routers, they are existing routers with new=20 >>> functionality. And as a vendor, I am trying to not require hardware=20= >>> changes to deploy the functionality. You will need a new software=20 >>> upgrade for the ITR/ETR. Let's see, in practice, if this turns out=20= >>> to be true. >> >> I think there is much more than that. >> If you want to perform the TE functionalities that have been=20 >> described in the LISP draft, you need to make the information about=20= >> the multiple locators available for an identifier to the ISP. Such=20 >> information is not available in the packet. So in order to allow the=20= >> intermediate ISP to acutally be able to reroute packet to altenrative=20= >> locators associated to the identifier contained in the inner header=20= >> of the packet, you must let the intermediate ISP discover the=20 >> alternative locator information. I am not sure how you are planning=20= >> to do this, but afict it will need much more infrastrucutre that what=20= >> currently is described in the draft. >> >> am i missing something? >> >> >> regards, marcelo >> >> >>>> We may want to continue looking for a clear split between locator=20= >>>> and ID, where >>>> locator describes topo location only, while ID uniquely names the=20= >>>> object with no >>>> reference to its location. 128-bit IPv6 has enough(?) room to=20 >>>> combine both in one >>>> source/destination descriptor. >>> >>> Well, what we want to do is get site's to have ingress packet=20 >>> traffic engineering, get better aggregation in both PE and P routers=20= >>> in the core, and to allow ISPs to reroute traffic through other ISPs=20= >>> (ISP-based TE). We can do this with this proposal. >>> >>> These are the requirements and goals we would like to focus on. If,=20= >>> at the same time, we get session survivability at any granularity,=20= >>> it is a bonus. >>> >>> Thanks again, >>> Dino >>> >>> _______________________________________________ >>> 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 > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 26 12:00: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 1HVrZi-0002Wc-KC; Mon, 26 Mar 2007 11:57:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVrZh-0002WW-E6 for ram@iab.org; Mon, 26 Mar 2007 11:57:37 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVrZf-0005wF-CE for ram@iab.org; Mon, 26 Mar 2007 11:57:37 -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 AD42B155ED; Mon, 26 Mar 2007 17:57:34 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Mar 2007 17:55:59 +0200 To: marcelo bagnulo braun From: JFC Morfin Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) In-Reply-To: <25677a9ed31e863414a481f1b5df5395@it.uc3m.es> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <20070326143722.A32C215668@smtp7-g19.free.fr> <25677a9ed31e863414a481f1b5df5395@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Message-Id: <20070326155734.AD42B155ED@smtp7-g19.free.fr> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 16:54 26/03/2007, marcelo bagnulo braun wrote: >El 26/03/2007, a las 16:20, JFC Morfin escribi=F3: >>Marcelo, >>I strongly oppose to that. > >i am not following you... exactly you strongly oppose to what? Dear Marcelo, I oppose to considering as a must what is for me a major security=20 violation: "to allow the intermediate ISP to acutally be able to=20 reroute packet to altenrative locators associated to the identifier=20 contained in the inner header of the packet, you must let the=20 intermediate ISP discover the alternative locator information" Or did I miss another position you expressed? Cheers. jfc >> For three major reasons: >> >>1) the internal packet may not be a TCP/IP packet (or a crypted=20 >>TCP/IP packet). This is why LISP is adequate to support=20 >>multitechnology systems. >>2) LISP permits the user to build and force his own routing=20 >>strategy. And to go through secure nodes (along his own criteria). >>3) depending on the final destination or on the content the ISP=20 >>could apply its own multi-tier strategy. >> >>This is why I tink the re-EIN concept should be reviewed together=20 >>with multi-level addressing and revived NIMROD topology report -=20 >>including information for LISP (and may be an addition to the DNS=20 >>to indicate the real nature of a given IP). >>jfc >> >>At 11:53 26/03/2007, marcelo bagnulo braun wrote: >> >>>El 26/03/2007, a las 0:44, Dino Farinacci escribi=F3: >>>>> >>>>>ISP and End User >>>>>1. Have to introduce 2 more sets of routers: ITP / ETP, which is=20 >>>>>an extra cost >>>> >>>>They are not new routers, they are existing routers with new=20 >>>>functionality. And as a vendor, I am trying to not require=20 >>>>hardware changes to deploy the functionality. You will need a new=20 >>>>software upgrade for the ITR/ETR. Let's see, in practice, if this=20 >>>>turns out to be true. >>> >>>I think there is much more than that. >>>If you want to perform the TE functionalities that have been=20 >>>described in the LISP draft, you need to make the information=20 >>>about the multiple locators available for an identifier to the=20 >>>ISP. Such information is not available in the packet. So in order=20 >>>to allow the intermediate ISP to acutally be able to reroute=20 >>>packet to altenrative locators associated to the identifier=20 >>>contained in the inner header of the packet, you must let the=20 >>>intermediate ISP discover the alternative locator information. I=20 >>>am not sure how you are planning to do this, but afict it will=20 >>>need much more infrastrucutre that what currently is described in the = draft. >>> >>>am i missing something? >>> >>> >>>regards, marcelo >>> >>> >>>>>We may want to continue looking for a clear split between=20 >>>>>locator and ID, where >>>>>locator describes topo location only, while ID uniquely names=20 >>>>>the object with no >>>>>reference to its location. 128-bit IPv6 has enough(?) room to=20 >>>>>combine both in one >>>>>source/destination descriptor. >>>> >>>>Well, what we want to do is get site's to have ingress packet=20 >>>>traffic engineering, get better aggregation in both PE and P=20 >>>>routers in the core, and to allow ISPs to reroute traffic through=20 >>>>other ISPs (ISP-based TE). We can do this with this proposal. >>>> >>>>These are the requirements and goals we would like to focus on.=20 >>>>If, at the same time, we get session survivability at any=20 >>>>granularity, it is a bonus. >>>> >>>>Thanks again, >>>>Dino >>>> >>>>_______________________________________________ >>>>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 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 26 14:30: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 1HVtuS-0007NG-Vu; Mon, 26 Mar 2007 14:27:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVtuS-0007Kf-1t for ram@iab.org; Mon, 26 Mar 2007 14:27:12 -0400 Received: from web58703.mail.re1.yahoo.com ([66.196.100.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HVtuQ-0005BW-O5 for ram@iab.org; Mon, 26 Mar 2007 14:27:12 -0400 Received: (qmail 1957 invoked by uid 60001); 26 Mar 2007 18:27:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=oSEu/J0bkiUJxldGlN+Ul+OB58mbOorFVowOimQ2l2dhoYd3WvIEzxbiwrt+TbDMr3n+X3Tgy7e6Gmj7tPgKV2ltZ9JJjAh7CmqcB/5x2buxx+fgNJzn/9mUn4QNramXbbhundf8e2R1WD3tfhCh3DRwydwBBO75n8H1+9e9o3I=; X-YMail-OSG: EgHtmZ8VM1nY_k.idvciidUwJICRK5cVvidXmCYAfjbGp8tzA6iptTPllKn6nsc146v5lbclX0KTgxXdUhZVNUxq96C56MBlEZCuxzJWZY__lSNXsKoVqPMPct2ccvnYmLmSaCNuCxxvXqpscxVrhnvgMnyMh6NRoLU3Tr69FZK7 Received: from [24.114.255.83] by web58703.mail.re1.yahoo.com via HTTP; Mon, 26 Mar 2007 11:27:10 PDT Date: Mon, 26 Mar 2007 11:27:10 -0700 (PDT) From: Peter Sherbin Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) To: Dino Farinacci In-Reply-To: <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <496007.1683.qm@web58703.mail.re1.yahoo.com> X-Spam-Score: 1.8 (+) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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 You will need a new software > upgrade for the ITR/ETR. Let's see, in practice, if this turns out to > be true. Yes as per the design goals LISP is clearly non-disruptive. Thanks, Peter --- Dino Farinacci wrote: > > I believe this very good draft is still a subject to comments and > > here it goes: > > Thanks for our comments. And they are certainly not coming too late. > > > General > > 1. Both EID and RLOC remain (IP) addresses of dual nature: locator > > & identifier. > > Hence actually there is no Locator/ID separation. > > There is a separation but at the network level and not the stack > level. Lixia, over last week used the term "multi-level addresses" > which I think is the case for LISP based EID and Locator terms. > > That is, the 'address' has scope depending where the ITR and ETR are > located in the source and destination site, respectively. > > So, if your ITR/ETR are on the first/last-hop routers, then the inner > "ID addresses" are used simply used as link-local (and as connection > IDs for the transport layer). > > If your ITR/ETR are at the CE edges of site, then the scope of the > "ID address" is used throughout the site. > > But we can say after a packet is tunneled, that the only addresses in > the outer header are certainly "Locator addresses". And are the ones > we want to aggregate-optimize in the PE and P routers in the core. > > We will make it more clear in the next draft that this separation is > network-based and has scope. > > > > > End User > > 1. Depends on ISP for RLOCs, the entire notion of PI is negated > > Yes, well we all depend on ISP address block allocation or else we > can't send packet globally. If you are a site, not attached to the > Internet, you can use RFC 1918 addresses, as you do today, to be used > as both EIDs and Locators within your site scope. If you need > mobility, you can deploy a LISP ITR and ETR inside of your site, and > have Locator reachability inside your "site core". But I believe most > sites won't need to do this. And that is goodness, because you can > run your network the way you do today, even in the new world of > separation (or in a "jack-up world"). > > > 2. Extra overhead > > Well yes, the cost of tunneling to get redirection is paid in terms > of additional header bytes. TANSTAFL. > > > > > ISP and End User > > 1. Have to introduce 2 more sets of routers: ITP / ETP, which is an > > extra cost > > They are not new routers, they are existing routers with new > functionality. And as a vendor, I am trying to not require hardware > changes to deploy the functionality. You will need a new software > upgrade for the ITR/ETR. Let's see, in practice, if this turns out to > be true. > > > We may want to continue looking for a clear split between locator > > and ID, where > > locator describes topo location only, while ID uniquely names the > > object with no > > reference to its location. 128-bit IPv6 has enough(?) room to > > combine both in one > > source/destination descriptor. > > Well, what we want to do is get site's to have ingress packet traffic > engineering, get better aggregation in both PE and P routers in the > core, and to allow ISPs to reroute traffic through other ISPs (ISP- > based TE). We can do this with this proposal. > > These are the requirements and goals we would like to focus on. If, > at the same time, we get session survivability at any granularity, it > is a bonus. > > Thanks again, > Dino > ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 26 15:47:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVv7d-0003zo-V9; Mon, 26 Mar 2007 15:44:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVv7d-0003zi-02 for ram@iab.org; Mon, 26 Mar 2007 15:44:53 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HVv7Z-0003vg-Vr for ram@iab.org; Mon, 26 Mar 2007 15:44:52 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 33E8E11493C; Mon, 26 Mar 2007 21:44:46 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id F084011491A; Mon, 26 Mar 2007 21:44:44 +0200 (CEST) Received: from 37.45.217.87.dynamic.jazztel.es (37.45.217.87.dynamic.jazztel.es [87.217.45.37]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Mon, 26 Mar 2007 21:44:41 +0200 Message-ID: <20070326214441.b26gatj9q5r4ogwk@webcartero01.uc3m.es> Date: Mon, 26 Mar 2007 21:44:41 +0200 From: MARCELO BAGNULO BRAUN To: JFC Morfin Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <20070326143722.A32C215668@smtp7-g19.free.fr> <25677a9ed31e863414a481f1b5df5395@it.uc3m.es> <20070326155734.AD42B155ED@smtp7-g19.free.fr> In-Reply-To: <20070326155734.AD42B155ED@smtp7-g19.free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Spam-Score: 1.5 (+) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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 JFC Morfin dijo: > At 16:54 26/03/2007, marcelo bagnulo braun wrote: >> El 26/03/2007, a las 16:20, JFC Morfin escribi=F3: >>> Marcelo, >>> I strongly oppose to that. >> >> i am not following you... exactly you strongly oppose to what? > > Dear Marcelo, > I oppose to considering as a must what is for me a major security > violation: "to allow the intermediate ISP to acutally be able to > reroute packet to altenrative locators associated to the identifier > contained in the inner header of the packet, you must let the > intermediate ISP discover the alternative locator information" > Or did I miss another position you expressed? i am not taking any position w.r.t. if this is a good idea or not. My point is that IF you want to enable the TE tools proposed in the LISP draft, you need to provide the information about the alternative locators associated to the identifier contained in the inner header to the intermediate ISP, and that this would imply additional mechanisms to be deployed in the intermediate ISP I am not taking any position whether this is a good idea or not, just trying to understand what is needed to provide the TE capabilities described in the LISP draft Since these mechanisms to distribute the altenrative locator information associated to an identifier are not described in the LISP draft, i am wondering if i am missing something regards, marcelo > Cheers. > jfc > >>> For three major reasons: >>> >>> 1) the internal packet may not be a TCP/IP packet (or a crypted >>> TCP/IP packet). This is why LISP is adequate to support >>> multitechnology systems. >>> 2) LISP permits the user to build and force his own routing >>> strategy. And to go through secure nodes (along his own criteria). >>> 3) depending on the final destination or on the content the ISP >>> could apply its own multi-tier strategy. >>> >>> This is why I tink the re-EIN concept should be reviewed together >>> with multi-level addressing and revived NIMROD topology report - >>> including information for LISP (and may be an addition to the DNS >>> to indicate the real nature of a given IP). >>> jfc >>> >>> At 11:53 26/03/2007, marcelo bagnulo braun wrote: >>> >>>> El 26/03/2007, a las 0:44, Dino Farinacci escribi=F3: >>>>>> >>>>>> ISP and End User >>>>>> 1. Have to introduce 2 more sets of routers: ITP / ETP, which is >>>>>> an extra cost >>>>> >>>>> They are not new routers, they are existing routers with new >>>>> functionality. And as a vendor, I am trying to not require >>>>> hardware changes to deploy the functionality. You will need a new >>>>> software upgrade for the ITR/ETR. Let's see, in practice, if this >>>>> turns out to be true. >>>> >>>> I think there is much more than that. >>>> If you want to perform the TE functionalities that have been >>>> described in the LISP draft, you need to make the information >>>> about the multiple locators available for an identifier to the >>>> ISP. Such information is not available in the packet. So in order >>>> to allow the intermediate ISP to acutally be able to reroute >>>> packet to altenrative locators associated to the identifier >>>> contained in the inner header of the packet, you must let the >>>> intermediate ISP discover the alternative locator information. I >>>> am not sure how you are planning to do this, but afict it will >>>> need much more infrastrucutre that what currently is described in >>>> the draft. >>>> >>>> am i missing something? >>>> >>>> >>>> regards, marcelo >>>> >>>> >>>>>> We may want to continue looking for a clear split between >>>>>> locator and ID, where >>>>>> locator describes topo location only, while ID uniquely names >>>>>> the object with no >>>>>> reference to its location. 128-bit IPv6 has enough(?) room to >>>>>> combine both in one >>>>>> source/destination descriptor. >>>>> >>>>> Well, what we want to do is get site's to have ingress packet >>>>> traffic engineering, get better aggregation in both PE and P >>>>> routers in the core, and to allow ISPs to reroute traffic through >>>>> other ISPs (ISP-based TE). We can do this with this proposal. >>>>> >>>>> These are the requirements and goals we would like to focus on. >>>>> If, at the same time, we get session survivability at any >>>>> granularity, it is a bonus. >>>>> >>>>> Thanks again, >>>>> Dino >>>>> >>>>> _______________________________________________ >>>>> 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 > > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Mar 26 17:32:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVwkP-0002no-If; Mon, 26 Mar 2007 17:29:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVwkO-0002m9-Gr for ram@iab.org; Mon, 26 Mar 2007 17:29:00 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVwk9-0002FO-Ro for ram@iab.org; Mon, 26 Mar 2007 17:28:52 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 26 Mar 2007 14:28:39 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l2QLSdkG019243; Mon, 26 Mar 2007 14:28:39 -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 l2QLScwn017488; Mon, 26 Mar 2007 21:28:38 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, 26 Mar 2007 14:28:38 -0700 Received: from [10.215.197.61] ([10.21.121.178]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 14:28:37 -0700 In-Reply-To: <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Mon, 26 Mar 2007 14:28:37 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Mar 2007 21:28:37.0821 (UTC) FILETIME=[B76636D0:01C76FED] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1249; t=1174944519; x=1175808519; 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]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=vlQx0QGd66P+T+KvBYfb2/XLJ5WcNYhAKzr3lrxV7fI=; b=nknuACA1x+xN7IGWLNncHIl0r4j6rb8kPd+nrTE7CVkOkC0GbPG8dNMlLnYKRza0UZCSbBYt w77Db5dAmBUXYqjeMrZ0cL0Qfbe4F3sKKFh+KHlSKZuimuINWhuEkiG6; 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: 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 >>> >>> ISP and End User >>> 1. Have to introduce 2 more sets of routers: ITP / ETP, which is >>> an extra cost >> >> They are not new routers, they are existing routers with new >> functionality. And as a vendor, I am trying to not require >> hardware changes to deploy the functionality. You will need a new >> software upgrade for the ITR/ETR. Let's see, in practice, if this >> turns out to be true. >> > > I think there is much more than that. > If you want to perform the TE functionalities that have been > described in the LISP draft, you need to make the information about > the multiple locators available for an identifier to the ISP. Such > information is not If the ISP needs the mappings it could get it, but according to the draft, the TE-ITR will look at outer headers and if the site ITR had prepended a header, the outer DA at the TE-ITR is a locator address. In the ISP's case, an equivalence class of prefixes will be associated with the TE-ITR's encapsulation. And this would be mostly static in nature. > am i missing something? The TE-ITR will not look at the inner header but the DA in the outer header against it's own database which is policy configured. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 27 04:18: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 1HW6oU-0006Yh-7a; Tue, 27 Mar 2007 04:13:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW6oS-0006YN-Qm for ram@iab.org; Tue, 27 Mar 2007 04:13:52 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HW6oR-0007Of-05 for ram@iab.org; Tue, 27 Mar 2007 04:13:52 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C6F7ABD6BC; Tue, 27 Mar 2007 10:13:49 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp03.uc3m.es (Postfix) with ESMTP id 8D07BBD3C1; Tue, 27 Mar 2007 10:13:49 +0200 (CEST) In-Reply-To: <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Tue, 27 Mar 2007 10:16:11 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 El 26/03/2007, a las 23:28, Dino Farinacci escribi=F3: >>>> >>>> ISP and End User >>>> 1. Have to introduce 2 more sets of routers: ITP / ETP, which is an=20= >>>> extra cost >>> >>> They are not new routers, they are existing routers with new=20 >>> functionality. And as a vendor, I am trying to not require hardware=20= >>> changes to deploy the functionality. You will need a new software=20 >>> upgrade for the ITR/ETR. Let's see, in practice, if this turns out=20= >>> to be true. >>> >> >> I think there is much more than that. >> If you want to perform the TE functionalities that have been=20 >> described in the LISP draft, you need to make the information about=20= >> the multiple locators available for an identifier to the ISP. Such=20 >> information is not > > If the ISP needs the mappings it could get it, but according to the=20 > draft, the TE-ITR will look at outer headers and if the site ITR had=20= > prepended a header, the outer DA at the TE-ITR is a locator address. > ok, so in this case the intermediate ISP should know that two (or more)=20= locators are equivalent (i.e. they are associated to the same=20 identifier (or potentially set of identifiers)), right? > In the ISP's case, an equivalence class of prefixes will be associated=20= > with the TE-ITR's encapsulation. And this would be mostly static in=20 > nature. > So, if i understand correctly an equivalence class of locators are all=20= the locators associated to an identifier (or a set of identifiers). In=20= particular, in the case of a multihomed site, an equivalence class is=20 the set of RLOC (i.e. of PA addresses) that are associated to the site,=20= right? in this case, i agree with the mostly static nature. But in any case, the intermediate ISP should be able to discover the=20 classes of equivalence of locators, i.e. all the locator sets that have=20= been associated to each multihomed site. I agree this could be done=20 manually, but i am not sure whether having to manually configure all=20 the sets of PA addresses associated to each multihomed site will be an=20= acceptable solution for a big ISP. I mean, we are saying that there=20 will be thousands of multihomed sites, right? I think some mechanisms=20 for automatically distributing the equivalemnce class information to=20 the intermediate ISPs will be needed if we want to make this=20 practical... for instance a parallel instance of BGP distributing this=20= information... regards, marcelo >> am i missing something? > > The TE-ITR will not look at the inner header but the DA in the outer=20= > header against it's own database which is policy configured. > > Dino > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 27 09:10: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 1HWBNq-0004LH-Ag; Tue, 27 Mar 2007 09:06:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWBNn-0004Kz-80 for ram@iab.org; Tue, 27 Mar 2007 09:06:39 -0400 Received: from [64.25.87.235] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWBNk-0001B3-Vy for ram@iab.org; Tue, 27 Mar 2007 09:06:39 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1996633 for ram@iab.org; Tue, 27 Mar 2007 09:06:29 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> Content-Transfer-Encoding: 7bit From: Margaret Wasserman Date: Tue, 27 Mar 2007 09:06:28 -0400 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [RAM] Incremental Deployment of LISP 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 All, I've been thinking about the incremental deployment of LISP, and I'm having trouble understanding what people mean by that... LISP does define 4 LISP "variants"-- one where both EIDs and RLOCs are globally routable, one where ICMP is used for the mapping from EIDs to RLOCs, one where DNS is used for that mapping, and one where another mechanism (TBD) is used. However, I don't understand how any of those variants can be deployed incrementally. In each of the LISP variants, traffic sent from a LISP-enabled network will travel through a LISP ITR where it will be encapsulated in an additional IP header containing one or two RLOCs. It is necessary for that traffic to travel through a LISP ETR on the receiving end, in order to have the outer header removed before it is forwarded to the final destination. End-nodes in LISP-enabled networks will not be able to communicate directly with end-nodes in non-LISP-enable networks, because non-LISP- enabled networks will not have ETRs at their borders to remove the additional IP header. So, it isn't actually possible to deploy LISP at the border of one end-user site or ISP network at a time (which is what I would consider incremental deployment); LISP can only be deployed in topologically closed regions of the Internet that are completely surrounded by LISP ETRs. We wouldn't see any DFZ route scaling benefits until the DFZ was entirely contained within a LISP region. The four variants would only seem to complicate deployment, IMO, because as various LISP regions join together, you would need to consider whether they are using the same LISP variant or not. Thoughts? Margaret _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Mar 27 16:11: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 1HWHzD-0004vZ-Tj; Tue, 27 Mar 2007 16:09:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWHzD-0004v6-7D for ram@iab.org; Tue, 27 Mar 2007 16:09:43 -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 1HWHz7-0008SR-US for ram@iab.org; Tue, 27 Mar 2007 16:09:43 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2RK9aPf000932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Mar 2007 15:09:37 -0500 (CDT) 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 l2RK9awa028623; Tue, 27 Mar 2007 15:09:36 -0500 (CDT) Received: from XCH-NWBH-10.nw.nos.boeing.com (xch-nwbh-10.nw.nos.boeing.com [130.247.55.83]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l2RK9Ysw028513; Tue, 27 Mar 2007 15:09:36 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 13:09:33 -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] Request to advance RFC4214 to Proposed Standard Date: Tue, 27 Mar 2007 13:09:33 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774830@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <46064728.4000805@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Request to advance RFC4214 to Proposed Standard Thread-Index: Acduw8c9+oJT4F7eRuidMXVcF9ciXgB5+vSw References: <39C363776A4E8C4A94691D2BD9D1C9A101774817@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A101774818@XCH-NW-7V2.nw.nos.boeing.com> <4606177E.9070405@piuha.net> <4606444E.1030409@zurich.ibm.com> <46064728.4000805@piuha.net> From: "Templin, Fred L" To: "Jari Arkko" , "Brian E Carpenter" X-OriginalArrivalTime: 27 Mar 2007 20:09:33.0679 (UTC) FILETIME=[D61557F0:01C770AB] 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 Sorry to have left this thread hanging, but this discussion has been moved over to the v6ops list. Thanks - Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Sunday, March 25, 2007 2:56 AM > To: Brian E Carpenter > Cc: Templin, Fred L; ram@iab.org; rfc-editor@rfc-editor.org > Subject: Re: [RAM] Request to advance RFC4214 to Proposed Standard >=20 > Sure -- the plans and opinions of an existing WG in this > space is an input to a sponsoring decision. But for now I > really just wanted to know why Fred thinks its relevant > for the RAM discussion. >=20 > Jari >=20 > Brian E Carpenter kirjoitti: > > Jari, > > > > Speaking as a long time participant in ngtrans/v6ops, > > I believe this request should only be addressed via v6ops, > > which, if I recall correctly, has as its established > > consensus to progress no more IPv6 coexistence techniques. > > > > I'm not saying that consensus can't be changed, but until > > it is, I'd be against AD sponsoring of this request > > (without any comment on the merits of this or other > > proposed additional coexistence techniques). > > > > Brian > > > > >=20 >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Mar 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 1HWaZS-0005F9-UD; Wed, 28 Mar 2007 12:00:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWaZG-0004y9-1q for ram@iab.org; Wed, 28 Mar 2007 12:00:10 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWaZE-0006Vr-Qn for ram@iab.org; Wed, 28 Mar 2007 12:00:10 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 28 Mar 2007 12:00:04 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2SG040p030433; Wed, 28 Mar 2007 12:00:04 -0400 Received: from [192.168.2.39] (rtp-vpn4-384.cisco.com [10.82.209.128]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2SFxqGd029527; Wed, 28 Mar 2007 15:59:58 GMT Message-ID: <460A90F5.10202@cisco.com> Date: Wed, 28 Mar 2007 11:59:49 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: JFC Morfin Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <20070326143722.A32C215668@smtp7-g19.free.fr> In-Reply-To: <20070326143722.A32C215668@smtp7-g19.free.fr> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1361; t=1175097604; x=1175961604; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20 |To:=20JFC=20Morfin=20; bh=Vqbpx8aeGAOkBC593O/WAVBa9/UzB1pPE2NvT2U0OZc=; b=ZpZKIvHWBvKL4ZkpIAa6X8Mze1CK15Pp602KnysE7jh0562vav5SCKZ7DrpThiK5YTxpg8Iz PNk7/+kZucG73JjQvVT6Eq5ylDXMgKk+15jj3lpFMqW8snOFblwyJ6FP; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 2) LISP permits the user to build and force his own routing strategy. > And to go through secure nodes (along his own criteria). > 3) depending on the final destination or on the content the ISP could > apply its own multi-tier strategy. These two are contradictory..... I can build a tunnel that forces my traffic to go along a specific path. Anyone along the path can, in turn, build a tunnel forcing my traffic to go along a different path. In general, path selection should not be a component of any security architecture, IMHO. Even if you turn this into a traffic engineering problem and solution, you have to remember that anyone in your path can destroy your traffic engineering with their traffic engineering. I actually think this is one of the "problems" we are trying to handle here, but it's "under the covers," in a sense, because the focus is on the table size, rather than the TE--but, from what I'm hearing, the table size is a direct result of the longest match routing traffic engineering that's being used today. :-) Russ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGCpD0ER27sUhU9OQRAkSuAJ9QyJKP4ddMUKZARZ+Ohj+XK9bwEACeJBPl EomHRNht6B7F+YKUxigJ88Y= =elym -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 13:39: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 1HWyYO-0001CU-5b; Thu, 29 Mar 2007 13:36:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWyYM-0001CN-W2 for ram@iab.org; Thu, 29 Mar 2007 13:36:50 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWyYK-0007bX-JQ for ram@iab.org; Thu, 29 Mar 2007 13:36:50 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Mar 2007 10:36:45 -0700 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 l2THajdN013020; Thu, 29 Mar 2007 10:36:45 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l2THagF6029778; Thu, 29 Mar 2007 17:36:44 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); Thu, 29 Mar 2007 10:36:30 -0700 Received: from [10.215.197.76] ([10.21.99.198]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 10:36:30 -0700 In-Reply-To: <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Thu, 29 Mar 2007 10:36:32 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Mar 2007 17:36:30.0201 (UTC) FILETIME=[C9214E90:01C77228] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2359; t=1175189805; x=1176053805; 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]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=wYpg/OpvzUayFZvqhFPJ1CgkQ20ZUCoJG+1HnJtn3BI=; b=nvkS6twOlA7gBPZDvEOCtg5kpL4F49dMDW/BXCpL98h9Bboqv0mj1laUrTXfGq+kW0Jv0FFh +VIH7KRui1pi+KDsoU4DfmXXK8GyOrSwnRIzcxHA1RJWHP4v037J0DRc; 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: 82c9bddb247d9ba4471160a9a865a5f3 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 the ISP needs the mappings it could get it, but according to >> the draft, the TE-ITR will look at outer headers and if the site >> ITR had prepended a header, the outer DA at the TE-ITR is a >> locator address. >> > > ok, so in this case the intermediate ISP should know that two (or > more) locators are equivalent (i.e. they are associated to the same > identifier (or potentially set of identifiers)), right? I don't know what you mean. The TE-ITR only needs to route on the outer DA so it would only need a FIB route that the DA would match. >> In the ISP's case, an equivalence class of prefixes will be >> associated with the TE-ITR's encapsulation. And this would be >> mostly static in nature. >> > > So, if i understand correctly an equivalence class of locators are > all the locators associated to an identifier (or a set of > identifiers). In particular, in the case of a multihomed site, an > equivalence class is the set of RLOC (i.e. of PA addresses) that > are associated to the site, right? No, it is the same way an ISP routes data for a set of prefixes across an IGP shortcut MPLS LSP. This is the same problem just using an IP tunnel to move large number of flows from going to one egress point to another. > But in any case, the intermediate ISP should be able to discover > the classes of equivalence of locators, i.e. all the locator sets > that have been associated to each multihomed site. I agree this > could be done We need to be clear here. We are talking about TE "inside a set of ISPs". So the TE-ITR would/could be the first-hop ISP and the TE-ETR could be at any transit ISP to get the packet to where the first LISP header says it should go. > manually, but i am not sure whether having to manually configure > all the sets of PA addresses associated to each multihomed site > will be an acceptable solution for a big ISP. I mean, we are saying > that there will be I am not suggesting that. > thousands of multihomed sites, right? I think some mechanisms for > automatically distributing the equivalemnce class information to > the intermediate ISPs will be needed if we want to make this > practical... for instance a parallel instance of BGP distributing > this information... Understand. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 14:07: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 1HWz0x-0005ij-S8; Thu, 29 Mar 2007 14:06:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWz0v-0005eu-Sb for ram@iab.org; Thu, 29 Mar 2007 14:06:21 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWz0u-00086B-8t for ram@iab.org; Thu, 29 Mar 2007 14:06:21 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Mar 2007 11:06:20 -0700 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 l2TI6Jsr018750; Thu, 29 Mar 2007 11:06:19 -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 l2TI6JEk021845; Thu, 29 Mar 2007 18:06:19 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); Thu, 29 Mar 2007 11:06:19 -0700 Received: from [10.215.197.76] ([10.21.99.198]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 11:06:19 -0700 In-Reply-To: <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 11:06:21 -0700 To: Margaret Wasserman X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Mar 2007 18:06:19.0135 (UTC) FILETIME=[F36AF8F0:01C7722C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5480; t=1175191579; x=1176055579; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=nBNZPCfnEjLRIBXKwQXvYk2i67y0v3qnbuKzvHmxL98=; b=1lB3YEBzxqAM6780+ps3aTiwT1ehnTQ3CYZN8lPgo6VH0kolSbvLB/QIaQMDyCru2p8WDaT/ UMIAI3ie1EpvU/KGgM9fNh17AFWM4i58Uet9UDrmNM0iwaI4Tm0g4FMQ; 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: 22bbb45ef41b733eb2d03ee71ece8243 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 > LISP does define 4 LISP "variants"-- one where both EIDs and RLOCs > are globally routable, one where ICMP is used for the mapping from > EIDs to RLOCs, one where DNS is used for that mapping, and one > where another mechanism (TBD) is used. However, I don't understand > how any of those variants can be deployed incrementally. LISP 1 can be deployed by adding either new boxes that do the ITR and ETR function or by configuring existing boxes, with a software upgrade, to do the ITR and ETR functions. The IDs are routable here so it is assumed those routes are in BGP today. What LISP 1 buys you is: 1) Inserting a level of indirection (jack-up). 2) Gives us experience with doing a Locator/ID split. 3) Determine how dynamic a locator reachability algorithm will behave. 4) Will on-demand caching of EID-to-RLOC and triggered mapping replies be sufficient to scale. LISP 1.5 gives you all the benefits of LISP 1 but the routable IDs can happen on another topology. Thereby allowing you to remove the routes that the IDs needed in LISP 1 to route on, from the BGP core. What LISP 1.5 buys you is: 1) Experience with allocating PI to sites but to not carry them in the BGP core. They would be carried in another topology. 2) We can get experience with aggregating EID-prefixes which now has no dependence on topology. This can give us data to determine the size, scope, and scale of a LISP 3 solution. LISP 2 allows a non-triggered approach by using a request/reply interface. By not adding any new infrastructure, it forces us to use the only scalable database we know about, that is DNS. The disadvantage of using DNS is: 1) Routing depends on directory and directory depends on routing. 2) RTT latency when doing the lookup. 3) Packet drops while waiting for reply to come into the ITR. LISP 2 *could* be a non-starter, but documented for completeness. LISP 3 allows us to be innovative and build something new that can scale to the requirements specifically for a Locator/ID split. So DNS and BGP are explicitly avoided and we give into building a new database. If we build a new database, we could have: 1) The mappings already stored in the ITRs so there is no packet drops and no latency. 2) We can secure the mapping database at the same time we figure out how to do the mapping distribution. Then we don't need an explicit PKI, we could make the distribution peering infrastructure store keys. 3) We keep the design simple (meaning we don't have to bastardize an existing mechanism to give us what we want, i.e. BGP), and we build in "lessons learned" from doing protocol design before. 4) We make it integrated in the sense to support both IPv4 and IPv6. > In each of the LISP variants, traffic sent from a LISP-enabled > network will travel through a LISP ITR where it will be > encapsulated in an additional IP header containing one or two > RLOCs. It is necessary for that traffic to When you prepend a new header, exactly one locator is put in the DA field. > travel through a LISP ETR on the receiving end, in order to have > the outer header removed before it is forwarded to the final > destination. Right. > End-nodes in LISP-enabled networks will not be able to communicate > directly with end-nodes in non-LISP-enable networks, because non- > LISP-enabled networks will not have ETRs at their borders to remove > the additional IP header. Correct. But an ITR will know if there is an ETR in the site. Otherwise, it has no locator address to encapsulate to. In LISP 1 and 1.5, when the inner DA is copied to the outer DA in the ITR and there is no ETR, the destination host will return an ICMP Protocol Unreachable message. In LISP 2 and 3, the ITR knows there is no ETR so the packet is routed natively and assumed the destination site's prefix is in the BGP core. > So, it isn't actually possible to deploy LISP at the border of one > end-user site or ISP network at a time (which is what I would > consider incremental deployment); LISP can only be deployed in > topologically closed regions of the Internet that are completely > surrounded by LISP ETRs. We wouldn't see any DFZ route scaling > benefits until the DFZ was entirely contained within a LISP region. Do you still think so from my defense above? > The four variants would only seem to complicate deployment, IMO, > because as We are not saying all 4 will be deployed. I envision this to be the roll-out sequence: o Prototype and "pilot deploy" LISP 1 and 1.5. Doing one implementation gets you both variants. o LISP 2 will probably not be used and thrown away. o LISP 3 will be developed to use DHTs or a push mechanism. As we deploy the LISP 3 variant, we will not be able to route IDs on the native core since we'll be removing prefixes from the BGP core. If we cannot retrieve the mappings via the LISP 3 mechanism, we could route the ID on the non-congruent topology ala LISP 1.5. If LISP 3 proves to work well, we can remove the alternate topology of LISP 1.5. It's hard to say this will be reality but we can all count on learning a lot along the way. Make more sense? Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 14:16: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 1HWz9i-0002Gq-6z; Thu, 29 Mar 2007 14:15:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWz9h-0002FS-6p for ram@iab.org; Thu, 29 Mar 2007 14:15:25 -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 1HWz7O-0001ih-3B for ram@iab.org; Thu, 29 Mar 2007 14:13:03 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2007 11:13:02 -0700 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 l2TID1AW017139 for ; Thu, 29 Mar 2007 11:13:01 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2TICvZT026191 for ; Thu, 29 Mar 2007 18:13:01 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2F3CB446-9DD5-4189-8A42-B25E5A269F61@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 11:13:10 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1067; t=1175191981; x=1176055981; c=relaxed/simple; s=sjdkim4002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=AdfotHB2BqMDr/Naob1x+tisPCIiZYp907l9ktBy7+I=; b=P4SWS7Tq0exbHZhlCdfFozAWcvg6hZldsDPZ/SQDhYS4nuploDgEanMmDeTwvbUKs+5J58KF HW5PwAZdXaXewXmM0eIaT+HlWR93wU8mnbxDNOWoDh1sKxYxJNC8LhaX; Authentication-Results: sj-dkim-4; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Mar 29, 2007, at 11:06 AM, Dino Farinacci wrote: > The disadvantage of using DNS is: > > 1) Routing depends on directory and directory depends on routing. > 2) RTT latency when doing the lookup. > 3) Packet drops while waiting for reply to come into the ITR. 4) The global DNS infrastructure wasn't designed/implemented to handle this kind of requirement, it's neither fast nor reliable enough, IMHO (works pretty well for its intended purpose, but DNS is a 'behind the scenes' kind of thing which is often neglected and certainly can't be made front-and-center as a requirement for routing). The mechanisms used for mappings in LISP or any other proposal should be contained within the network infrastructure and simply cannot have a dependency upon any other external system, IMHO. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 15:18: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 1HX066-0005ag-Jt; Thu, 29 Mar 2007 15:15:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX064-0005YT-A7 for ram@iab.org; Thu, 29 Mar 2007 15:15:44 -0400 Received: from imo-d04.mx.aol.com ([205.188.157.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWzxL-0007nS-AR for ram@iab.org; Thu, 29 Mar 2007 15:06:44 -0400 Received: from HeinerHummel@aol.com by imo-d04.mx.aol.com (mail_out_v38_r8.1.) id c.d25.aa8b497 (42805); Thu, 29 Mar 2007 15:06:37 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Thu, 29 Mar 2007 15:06:36 EDT Subject: Re: [RAM] Incremental Deployment of LISP To: rdobbins@cisco.com, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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="===============1840029858==" Errors-To: ram-bounces@iab.org --===============1840029858== Content-Type: multipart/alternative; boundary="-----------------------------1175195196" -------------------------------1175195196 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Yes, and isn't this the origin task of any routing protocol to advertise =20 WHERE some user is located ? (rather than the task of DNS ?), i.e. to =20 communicate to the rest of the internet "I have reachability to this or that= user ?" =20 Heiner =20 In einer eMail vom 29.03.2007 20:16:25 Westeurop=E4ische Normalzeit schreibt= =20 rdobbins@cisco.com: On Mar 29, 2007, at 11:06 AM, Dino Farinacci wrote: > The disadvantage of using DNS is: > > 1) Routing depends on directory and directory depends on routing. > 2) RTT latency when doing the lookup. > 3) Packet drops while waiting for reply to come into the ITR. 4) The global DNS infrastructure wasn't designed/implemented to =20 handle this kind of requirement, it's neither fast nor reliable =20 enough, IMHO (works pretty well for its intended purpose, but DNS is =20 a 'behind the scenes' kind of thing which is often neglected and =20 certainly can't be made front-and-center as a requirement for routing). The mechanisms used for mappings in LISP or any other proposal should =20 be contained within the network infrastructure and simply cannot have =20 a dependency upon any other external system, IMHO. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram =20 -------------------------------1175195196 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Yes, and isn't this the origin task of any routing protocol to advertis= e=20 WHERE some user is located ? (rather than the task of DNS ?), i.e. to=20 communicate to the rest of the internet "I have reachability to this or that= =20 user ?"
 
Heiner
 
In einer eMail vom 29.03.2007 20:16:25 Westeurop=E4ische Normalzeit sch= reibt=20 rdobbins@cisco.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On Mar=20 29, 2007, at 11:06 AM, Dino Farinacci wrote:

> The disadvantage=20= of=20 using DNS is:
>
>     1) Routing depends on=20 directory and directory depends on routing.
>     2)=20= RTT=20 latency when doing the lookup.
>     3) Packet drops=20 while waiting for reply to come into the ITR.

4) The global DNS=20 infrastructure wasn't designed/implemented to 
handle this kind o= f=20 requirement, it's neither fast nor reliable 
enough, IMHO (works=20 pretty well for its intended purpose, but DNS is 
a 'behind the=20 scenes' kind of thing which is often neglected and 
certainly can= 't=20 be made front-and-center as a requirement for routing).

The mechani= sms=20 used for mappings in LISP or any other proposal should 
be contai= ned=20 within the network infrastructure and simply cannot have 
a=20 dependency upon any other external system,=20 IMHO.

-------------------------------------------------------------= ----------
Roland=20 Dobbins <rdobbins@cisco.com> // 408.527.6376 voice

  &nb= sp;=20      Words that come from a machine have no soul.

&n= bsp;=20                     = ; --=20 Duong Van=20 Ngo


_______________________________________________
RAM mail= ing=20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 
 -------------------------------1175195196-- --===============1840029858== 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 --===============1840029858==-- From ram-bounces@iab.org Thu Mar 29 15:29: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 1HX0Iw-0001xE-LN; Thu, 29 Mar 2007 15:29:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0Iu-0001x8-T6 for ram@iab.org; Thu, 29 Mar 2007 15:29:00 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX0It-00037g-NA for ram@iab.org; Thu, 29 Mar 2007 15:29:00 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4630E87323; Thu, 29 Mar 2007 15:28:59 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Incremental Deployment of LISP Message-Id: <20070329192859.4630E87323@mercury.lcs.mit.edu> Date: Thu, 29 Mar 2007 15:28:59 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: jnc@mercury.lcs.mit.edu 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: HeinerHummel@aol.com > Yes, and isn't this the origin task of any routing protocol to > advertise WHERE some user is located ? (rather than the task of DNS ?), > i.e. to communicate to the rest of the internet "I have reachability to > this or that user ?" "[saying] where some user is" and "communicating ... I have reachability to this or that" are two entirely different things - or rather, they can be, and have been for many decades now in most networking designs, separated into two different tasks. It's a general law of system design that as systems grow, it's usually the case that a single mechanism A that did both X and Y needs to get separated into two separate mechanisms B and C, one each for X and Y - which means that it would be an extremely bad idea to go in the reverse direction as a system got larger. In other words, trying to do both: - finding out where some user/computer/etc is, and - finding out if/how to get there in a single mechanism would be a really bad idea. "All problems in computer science can be solved with another level of indirection" - variously attributed to Butler Lampson and David Wheeler. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 15:35:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0PJ-0000Sp-IJ; Thu, 29 Mar 2007 15:35:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0PI-0000Sd-8H for ram@iab.org; Thu, 29 Mar 2007 15:35:36 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX0PG-0003kL-Vm for ram@iab.org; Thu, 29 Mar 2007 15:35:36 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 29 Mar 2007 12:35:34 -0700 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 l2TJZYpT027461 for ; Thu, 29 Mar 2007 12:35:34 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2TJZYwn016449 for ; Thu, 29 Mar 2007 19:35:34 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070329192859.4630E87323@mercury.lcs.mit.edu> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 12:35:47 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=960; t=1175196934; x=1176060934; c=relaxed/simple; s=sjdkim8002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=urWhUkgTaEjKbw5TWFJw1lkV2MPMOM0MPeTHiUNNLc4=; b=qTy3V5tnOTkcHsKQST9cnivuc8tupyXkUxyLYidxyg0q5oOyd4W1j22KAC3K26g0Sn+RlOtP WaZ1tTOiSfnuEbND6h4HxNhdV0DnZTmRUbibx3bV8h4Qtf53GGPNhHNa; Authentication-Results: sj-dkim-8; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Mar 29, 2007, at 12:28 PM, Noel Chiappa wrote: > It's a general law of system design that as systems grow, it's > usually the > case that a single mechanism A that did both X and Y needs to get > separated > into two separate mechanisms B and C, one each for X and Y - which > means that > it would be an extremely bad idea to go in the reverse direction as > a system > got larger. > > In other words, trying to do both: > - finding out where some user/computer/etc is, and > - finding out if/how to get there > in a single mechanism would be a really bad idea. The DNS won't work, and deploying some other infrastructure (X.500? Something Else?) to handle lookups is a nonstarter, IMHO. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 15:41:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0U3-00065k-Ac; Thu, 29 Mar 2007 15:40:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0U2-00061l-IZ for ram@iab.org; Thu, 29 Mar 2007 15:40:30 -0400 Received: from imo-m14.mx.aol.com ([64.12.138.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX0U0-0004JW-Rc for ram@iab.org; Thu, 29 Mar 2007 15:40:30 -0400 Received: from HeinerHummel@aol.com by imo-m14.mx.aol.com (mail_out_v38_r8.1.) id 9.cd1.b1e5f94 (42805); Thu, 29 Mar 2007 15:40:15 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Thu, 29 Mar 2007 15:40:18 EDT Subject: Re: [RAM] Incremental Deployment of LISP To: jnc@mercury.lcs.mit.edu, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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="===============0420288668==" Errors-To: ram-bounces@iab.org --===============0420288668== Content-Type: multipart/alternative; boundary="-----------------------------1175197218" -------------------------------1175197218 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 > Yes, and isn't this the origin task of any routing protocol to > advertise WHERE some user is located ? (rather than the task of DNS ?), > i.e. to communicate to the rest of the internet "I have reachability to > this or that user ?" "[saying] where some user is" and "communicating ... I have reachability to this or that" are two entirely different things - or rather, they can be, a= nd have been for many decades now in most networking designs, separated into t= wo different tasks. =20 C'mon. It's a general law of system design that as systems grow, it's usually the case that a single mechanism A that did both X and Y needs to get separated into two separate mechanisms B and C, one each for X and Y - which means th= at it would be an extremely bad idea to go in the reverse direction as a syste= m got larger. In other words, trying to do both: - finding out where some user/computer/etc is, and - finding out if/how to get there in a single mechanism would be a really bad idea. =20 I said more or less: communicating to all others "I have reachability to =20 this or that user" is the origin task of any routing protocol. What is wrong= =20 with this statement ? Can you put it in better words ? Or is my statement w= rong? Why do you come with such an answer ? =20 Heiner "All problems in computer science can be solved with another level of indirection" - variously attributed to Butler Lampson and David Wheeler. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram =20 -------------------------------1175197218 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
    > Yes, and isn't this the origin task of any=20 routing protocol to
    > advertise WHERE some user is locat= ed ?=20 (rather than the task of DNS ?),
    > i.e. to communicate t= o=20 the rest of the internet "I have reachability to
    > this=20= or=20 that user ?"

"[saying] where some user is" and "communicating ... I h= ave=20 reachability to
this or that" are two entirely different things - or rath= er,=20 they can be, and
have been for many decades now in most networking design= s,=20 separated into two
different tasks.
 
C'mon.


It's a general law of system design that as systems grow, it's=20 usually the
case that a single mechanism A that did both X and Y needs to= get=20 separated
into two separate mechanisms B and C, one each for X and Y - wh= ich=20 means that
it would be an extremely bad idea to go in the reverse directi= on=20 as a system
got larger.

In other words, trying to do both:
-=20 finding out where some user/computer/etc is, and
- finding out if/how to=20= get=20 there
in a single mechanism would be a really bad idea.
 
I said more or less: communicating to all others "I have reachability t= o=20 this or that user" is the origin task of any routing protocol. What is wrong= =20 with this statement ? Can you put it in better words ? Or is my statement=20 wrong?
Why do you come with such an answer ?
 
Heiner


"All problems in computer science can be solved with another le= vel=20 of
indirection" - variously attributed to Butler Lampson and David=20 Wheeler.

   =20 Noel

_______________________________________________
RAM mailing=20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
<= /FONT>
 
 -------------------------------1175197218-- --===============0420288668== 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 --===============0420288668==-- From ram-bounces@iab.org Thu Mar 29 15:53:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0fS-0003cQ-3P; Thu, 29 Mar 2007 15:52:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0fQ-0003bF-0r for ram@iab.org; Thu, 29 Mar 2007 15:52:16 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX0f8-0005t7-A5 for ram@iab.org; Thu, 29 Mar 2007 15:52:15 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0929B87324; Thu, 29 Mar 2007 15:51:57 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Incremental Deployment of LISP Message-Id: <20070329195157.0929B87324@mercury.lcs.mit.edu> Date: Thu, 29 Mar 2007 15:51:57 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: jnc@mercury.lcs.mit.edu 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: HeinerHummel@aol.com >> "[saying] where some user is" and "communicating ... I have >> reachability to this or that" are two entirely different things >> ... >> In other words, trying to do both: >> - finding out where some user/computer/etc is, and >> - finding out if/how to get there >> in a single mechanism would be a really bad idea. > Can you put it in better words? Here's a real-world analogy that might make it clearer. Let's say you want to visit a friend's house (the real-world equivalent of sending packets to another computer). The first step above is equivalent to finding out where the friend's house is - i.e. their street address. The second step is finding out how to get there (either finding a public transport system such as bus or subway that gets there, or looking at a map to see how to bike/drive/etc there). Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 15:54: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 1HX0hY-0003yW-5X; Thu, 29 Mar 2007 15:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0hX-0003yQ-1F for ram@iab.org; Thu, 29 Mar 2007 15:54:27 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX0hV-0006VS-Rt for ram@iab.org; Thu, 29 Mar 2007 15:54:27 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A5F4C87324; Thu, 29 Mar 2007 15:54:25 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Incremental Deployment of LISP Message-Id: <20070329195425.A5F4C87324@mercury.lcs.mit.edu> Date: Thu, 29 Mar 2007 15:54:25 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: jnc@mercury.lcs.mit.edu 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: Roland Dobbins > The DNS won't work, and deploying some other infrastructure .. to > handle lookups is a nonstarter, IMHO. OK, so what will work? :-) More of what we've already got, because anything else is too painful to deploy? Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 16:07: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 1HX0tG-0003aY-8a; Thu, 29 Mar 2007 16:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0tE-0003XN-Un for ram@iab.org; Thu, 29 Mar 2007 16:06:32 -0400 Received: from imo-d20.mx.aol.com ([205.188.139.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX0tD-0008HR-MZ for ram@iab.org; Thu, 29 Mar 2007 16:06:32 -0400 Received: from HeinerHummel@aol.com by imo-d20.mx.aol.com (mail_out_v38_r8.1.) id 9.be4.13d48df4 (42805); Thu, 29 Mar 2007 16:06:02 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Thu, 29 Mar 2007 15:06:26 EST Subject: Re: [RAM] Incremental Deployment of LISP To: jnc@mercury.lcs.mit.edu, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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="===============1399020813==" Errors-To: ram-bounces@iab.org --===============1399020813== Content-Type: multipart/alternative; boundary="-----------------------------1175198786" -------------------------------1175198786 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 "Saying where some user is" and "communicating, I have reachability to this=20= =20 or that" relates to the same, which is, at which node you may find that guy= . =20 How to get there is of course a different thing.=20 =20 I think we don't have that different opinions as it may look like, right ? =20 Heiner =20 =20 In einer eMail vom 29.03.2007 21:52:52 Westeurop=E4ische Normalzeit schreibt= =20 jnc@mercury.lcs.mit.edu: > From: HeinerHummel@aol.com >> "[saying] where some user is" and "communicating ... I have >> reachability to this or that" are two entirely different things >> ... >> In other words, trying to do both: >> - finding out where some user/computer/etc is, and >> - finding out if/how to get there >> in a single mechanism would be a really bad idea. > Can you put it in better words? Here's a real-world analogy that might make it clearer. Let's say you want to visit a friend's house (the real-world equivalent of sending packets to another computer). The first step above is equivalent to finding out where the friend's house is - i.e. their street address. The second step is finding out how to get there (either finding a public transport system such as bus or subway that gets there, or looking at a map to see how to bike/drive/etc there). Noel =20 -------------------------------1175198786 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
"Saying where some user is" and "communicating, I have reachability to=20= this=20 or that" relates to the same, which is, at which node you may find that=20 guy.
 
How to get there is of course a different thing.
 
I think we don't have that different opinions as it may look like, righ= t=20 ?
 
Heiner
 
 
In einer eMail vom 29.03.2007 21:52:52 Westeurop=E4ische Normalzeit sch= reibt=20 jnc@mercury.lcs.mit.edu:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2> =20 > From: HeinerHummel@aol.com

    >> "[saying] wh= ere=20 some user is" and "communicating ... I have
    >>=20 reachability to this or that" are two entirely different things
 =20   >> ...
    >> In other words, trying to do= =20 both:
    >> - finding out where some user/computer/etc= is,=20 and
    >> - finding out if/how to get there
 =20   >> in a single mechanism would be a really bad=20 idea.

    > Can you put it in better words?

Her= e's=20 a real-world analogy that might make it clearer.

Let's say you want= to=20 visit a friend's house (the real-world equivalent of
sending packets to= =20 another computer). The first step above is equivalent to
finding out wh= ere=20 the friend's house is - i.e. their street address. The
second step is=20 finding out how to get there (either finding a public
transport system=20= such=20 as bus or subway that gets there, or looking at a map
to see how to=20 bike/drive/etc there).

    Noel
 
-------------------------------1175198786-- --===============1399020813== 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 --===============1399020813==-- From ram-bounces@iab.org Thu Mar 29 16:08: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 1HX0uf-0006kQ-Gh; Thu, 29 Mar 2007 16:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX0ud-0006kL-P0 for ram@iab.org; Thu, 29 Mar 2007 16:07:59 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX0uc-0008Ty-Ff for ram@iab.org; Thu, 29 Mar 2007 16:07:59 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 29 Mar 2007 13:07:57 -0700 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 l2TK7tk6027200 for ; Thu, 29 Mar 2007 13:07:55 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2TK7tA8022481 for ; Thu, 29 Mar 2007 20:07:55 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070329195425.A5F4C87324@mercury.lcs.mit.edu> References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 13:08:09 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1292; t=1175198875; x=1176062875; c=relaxed/simple; s=sjdkim5002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=53pH+0Mky9J2HhpkeKZBG13hTyk3cPHX4AZgfRBKtb0=; b=blsK+o88YW54R8vp9t/Dq7qFNgwLuLRuGFl9zap7MGKr4wgH/yg8pir8yyY1hFKJlFrtRJxg aHpDOWxd/APULGqv/i0Me5Qeo2sEGVGIKp+IAJjijSpS4KeVTH0levGM; Authentication-Results: sj-dkim-5; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Mar 29, 2007, at 12:54 PM, Noel Chiappa wrote: > More of what we've already got, because anything > else is too painful to deploy? Essentially, yes - updated routing protocols, some new lookup service deployed -on the network infrastructure devices themselves and operated by the network infrastructure operators themselves-, etc. But the entire workable solution has to be within the realm of the network infrastructure, there can't be any dependencies upon sysadmin groups, etc., because of the silos (both natural and unnatural) in which the relevant skillsets and responsibilities and interests of these groups seem to pretty much universally reside. In other works, router jockeys are generally just router jockeys, and not sysadmins, too; box jockeys are generally just box jockeys, and not router-monkeys, too. And never the twain shall meet for architectural purposes, rarely enough even for operational purposes, unfortunately. So, the lookup function must be self-contained/- maintained, IMHO. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 16:15: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 1HX11Z-0004KI-NR; Thu, 29 Mar 2007 16:15:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX11Y-0004Ey-Dg for ram@iab.org; Thu, 29 Mar 2007 16:15:08 -0400 Received: from imo-m26.mx.aol.com ([64.12.137.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX11X-0000vZ-4R for ram@iab.org; Thu, 29 Mar 2007 16:15:08 -0400 Received: from HeinerHummel@aol.com by imo-m26.mx.aol.com (mail_out_v38_r7.10.) id 9.d58.59b4ba5 (42805); Thu, 29 Mar 2007 16:14:55 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Thu, 29 Mar 2007 16:14:55 EDT Subject: Re: [RAM] Incremental Deployment of LISP To: jnc@mercury.lcs.mit.edu, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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="===============0390523282==" Errors-To: ram-bounces@iab.org --===============0390523282== Content-Type: multipart/alternative; boundary="-----------------------------1175199295" -------------------------------1175199295 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 How about a new routing protocol and a new IPvN which a) overcomes all the =20 scalability problems and catches up with postal letter forwarding as done f= or=20 centuries with two parts written on the envelope: 1) Name of receiver (plus= =20 Mr. or Mrs,...) and maybe a little bit lower 2) street and number, zipcode and city, plus =20 country. =20 As a kid when I learned where to place these parts, I had no idea about =20 endpoint identifier /locator split :-) =20 Heiner =20 =20 In einer eMail vom 29.03.2007 21:54:43 Westeurop=E4ische Normalzeit schreibt= =20 jnc@mercury.lcs.mit.edu: > From: Roland Dobbins > The DNS won't work, and deploying some other infrastructure .. to > handle lookups is a nonstarter, IMHO. OK, so what will work? :-) More of what we've already got, because anything else is too painful to deploy? Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram =20 -------------------------------1175199295 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
How about a new routing protocol and a new IPvN which a) overcomes all=20= the=20 scalability problems and catches up with postal letter forwarding as do= ne=20  for centuries with two parts written on the envelope: 1) Name of recei= ver=20 (plus Mr. or Mrs,...)
and maybe a little bit lower 2) street and number, zipcode and city, pl= us=20 country.
 
As a kid when I learned where to place these parts, I had no idea about= =20 endpoint identifier /locator split :-)
 
Heiner
 
 
In einer eMail vom 29.03.2007 21:54:43 Westeurop=E4ische Normalzeit sch= reibt=20 jnc@mercury.lcs.mit.edu:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2> =20 > From: Roland Dobbins <rdobbins@cisco.com>

   =20= >=20 The DNS won't work, and deploying some other infrastructure .. to
 = ;=20   > handle lookups is a nonstarter, IMHO.

OK, so what will=20 work? :-) More of what we've already got, because anything
else is too=20 painful to deploy?

   =20 Noel

_______________________________________________
RAM mailing= =20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 
 -------------------------------1175199295-- --===============0390523282== 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 --===============0390523282==-- From ram-bounces@iab.org Thu Mar 29 17:22: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 1HX22G-0005kM-KF; Thu, 29 Mar 2007 17:19:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX22F-0005kG-SH for ram@iab.org; Thu, 29 Mar 2007 17:19:55 -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 1HX22C-0005BR-Ia for ram@iab.org; Thu, 29 Mar 2007 17:19:55 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2TLJpDC019289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Mar 2007 14:19:51 -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 l2TLJodj028313; Thu, 29 Mar 2007 14:19:50 -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 l2TLJlj6028207; Thu, 29 Mar 2007 14:19:50 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 14:19:50 -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] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 14:19:49 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: AcdyPgCUjAC3iXj4TP+sUAyM7dfUzwAByvPg References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu> <0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com> From: "Fleischman, Eric" To: , X-OriginalArrivalTime: 29 Mar 2007 21:19:50.0418 (UTC) FILETIME=[FC482720:01C77247] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 >Essentially, yes - updated routing protocols, some new lookup service deployed=20 >-on the network infrastructure devices themselves and operated by the network=20 >infrastructure operators themselves-, etc. An operative design consideration is how stable the interfaces are between the transit domain (e.g., the ISP-supported Internet) and the supported enclave (e.g., a corporation's AS). Many relationships will be very stable such that the interface pairings are essentially constant due to the (often substantial) inertia of established business relationships between a corporation and its ISP(s). In such common situations, I would imagine that such pairings, which constitute the DNS entries, can last for years or even decades such that even very old DNS entries will be adequate. Conceivably, other relationships may be briefer in duration, requiring DNS updates to occur at a higher rate. But what is the worst case (i.e., most brief) address pairings that are currently anticipated and what are the environmental factors that determine that rate (e.g., what environments are we actually worrying about in this discussion)?=20 Put another way, I don't understand why this proposed use of DNS would be any worse (i.e., more challenged) than current uses of DNS for identifying mail servers or other traditionally supported services. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 17:28: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 1HX29S-0003Fb-HJ; Thu, 29 Mar 2007 17:27:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX29Q-0003DD-Ad for ram@iab.org; Thu, 29 Mar 2007 17:27:20 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX27P-00067m-AH for ram@iab.org; Thu, 29 Mar 2007 17:25:16 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 29 Mar 2007 14:25:16 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l2TLPEbW009635 for ; Thu, 29 Mar 2007 14:25:14 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2TLPEwn027235 for ; Thu, 29 Mar 2007 21:25:14 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com> References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu> <0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com> <474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 14:25:27 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1025; t=1175203514; x=1176067514; c=relaxed/simple; s=sjdkim6002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=4+NA+h+uoOVFYcVNpc0Sp9WJAWnnOXvlnhaEX38grHk=; b=pRnF4XTjkWULMgnqNsFRcDK+22c5J2cMpord7KrPVvrvy7uNV3r686zoAUwdM0XsXH3SwNdU xh7iMlV6YdIcwmctF/eBJ/hxf81zlrTTGRTAVLo7d5Bu+7tBQxRbmai3; Authentication-Results: sj-dkim-6; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); 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 On Mar 29, 2007, at 2:19 PM, Fleischman, Eric wrote: > Put another way, I don't understand why this proposed use of DNS would > be any worse (i.e., more challenged) than current uses of DNS for > identifying mail servers or other traditionally supported services. Because there will be a -lot- more lookups, critical to -all- communications relationships, everywhere. DNS flakiness certainly can result in service/communications unavailability, but it isn't a guarantee. And the DNS contains a mess of unpatched, insecure hosts which nobody maintains - this is true of routers and other network infrastructure too, to some extent, but less than the DNS, IMHO, and, unlike DNS servers, these devices will -have- to be upgraded to work with the new system. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 17:33: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 1HX2F1-0001Hu-1n; Thu, 29 Mar 2007 17:33:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2F0-0001FS-6Q for ram@iab.org; Thu, 29 Mar 2007 17:33:06 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX2Ey-0008JL-RF for ram@iab.org; Thu, 29 Mar 2007 17:33:06 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l2TLWxd5013459; Thu, 29 Mar 2007 13:32:59 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l2TLWx0h013458; Thu, 29 Mar 2007 13:32:59 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 29 Mar 2007 13:32:59 -0800 From: David Meyer To: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Message-ID: <20070329213259.GA13108@1-4-5.net> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> <2F3CB446-9DD5-4189-8A42-B25E5A269F61@cisco.com> Mime-Version: 1.0 In-Reply-To: <2F3CB446-9DD5-4189-8A42-B25E5A269F61@cisco.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "No wasted time, we're alive today, Churnin up the past, there's no easier way, Time's been between us, a means to an end, G_d it's good to be here walking together my friend" -- srv, Life By The Drop X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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="===============1414406729==" Errors-To: ram-bounces@iab.org --===============1414406729== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2007 at 11:13:10AM -0700, Roland Dobbins wrote: >=20 > On Mar 29, 2007, at 11:06 AM, Dino Farinacci wrote: >=20 > >The disadvantage of using DNS is: > > > > 1) Routing depends on directory and directory depends on routing. > > 2) RTT latency when doing the lookup. > > 3) Packet drops while waiting for reply to come into the ITR. >=20 > 4) The global DNS infrastructure wasn't designed/implemented to =20 > handle this kind of requirement, it's neither fast nor reliable =20 > enough, IMHO (works pretty well for its intended purpose, but DNS is =20 > a 'behind the scenes' kind of thing which is often neglected and =20 > certainly can't be made front-and-center as a requirement for routing). Ever looked at a NAPTR record? In any event, I'm not in favor of using DNS as an auxillary rouing database, but it is happing (at least at the application routing level). Sort of suggests that a more general database functionality might be needed/missing. > The mechanisms used for mappings in LISP or any other proposal should =20 > be contained within the network infrastructure and simply cannot have =20 > a dependency upon any other external system, IMHO. "No circular dependencies" -- A long held Internet design principle dating back to Postel (or maybe before).=20 --dmm --FCuugMFkClbJLl1L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD4DBQFGDDCLORgD1qCZ2KcRAhLrAJ91x+q8ilIxOateM5zOi+kGPZpm5QCYgTAs 9ZPTD1QiiaT7hidW8Zv8AA== =Vyc8 -----END PGP SIGNATURE----- --FCuugMFkClbJLl1L-- --===============1414406729== 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 --===============1414406729==-- From ram-bounces@iab.org Thu Mar 29 17:36: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 1HX2IF-0003gI-4n; Thu, 29 Mar 2007 17:36:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2IC-0003bK-Bk for ram@iab.org; Thu, 29 Mar 2007 17:36: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 1HX2I9-00012T-Uo for ram@iab.org; Thu, 29 Mar 2007 17:36:24 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 29 Mar 2007 14:36:21 -0700 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 l2TLaLfG019903; Thu, 29 Mar 2007 14:36:21 -0700 Received: from [128.107.114.151] (dhcp-128-107-114-151.cisco.com [128.107.114.151]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2TLaLZT004024; Thu, 29 Mar 2007 21:36:21 GMT Message-ID: <460C3155.6050609@cisco.com> Date: Thu, 29 Mar 2007 17:36:21 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: David Meyer Subject: Re: [RAM] Incremental Deployment of LISP References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> <2F3CB446-9DD5-4189-8A42-B25E5A269F61@cisco.com> <20070329213259.GA13108@1-4-5.net> In-Reply-To: <20070329213259.GA13108@1-4-5.net> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1002; t=1175204181; x=1176068181; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=DVI9s1tmZVa9oOUU/9IbFrRdIXkOy0WNdlE+7lzaCtg=; b=niLhZrQp3Fm+7vipjKOEjbVfLGMxprW1fPQGsukRd6802oOTu5H2x0z5SgjJPpNCsDMqvgJy wxxOnUHfxrYFw8aaupUQBV/baBQlLVFdt8kqf6cIfBLZIJOxxsdDiJtIAnCyzv6OST4TRazBV1 RzDOYJ41WGTSK8grlAakjbkGo=; Authentication-Results: sj-dkim-1; header.From=riw@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Ever looked at a NAPTR record? In any event, I'm not in > favor of using DNS as an auxillary rouing database, but > it is happing (at least at the application routing > level). Sort of suggests that a more general database > functionality might be needed/missing. Which begs the question--is the root of the problem the current structure of DNS, perhaps? Is it worth looking at something to replace DNS, rather than something to shim between DNS and IP? > "No circular dependencies" -- A long held Internet > design principle dating back to Postel (or maybe > before). This rules out any sort of locator/id split that doesn't use a push model of locator/id mapping, I think. :-) Russ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGDDFVER27sUhU9OQRAunMAJ9bv+XMC1ClGYwR8Vh5E5Iqf0MdbQCfbYJ2 PpwL/fbnC7swXTvCDKEhKrw= =AWgF -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 17:42: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 1HX2NI-000744-Sl; Thu, 29 Mar 2007 17:41:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2NH-00073y-RI for ram@iab.org; Thu, 29 Mar 2007 17:41: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 1HX2N6-0002gy-QV for ram@iab.org; Thu, 29 Mar 2007 17:41:39 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2TLfSum001222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Mar 2007 14:41:28 -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 l2TLfRRZ001873; Thu, 29 Mar 2007 14:41:27 -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 l2TLfKr4001576; Thu, 29 Mar 2007 14:41:26 -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); Thu, 29 Mar 2007 14:41:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 14:41:24 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774857@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: AcdySTZIw85vGGaBQKqUUs5gmq/f0gAAU4BA References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu><0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com><474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com> <05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com> From: "Templin, Fred L" To: "Roland Dobbins" , X-OriginalArrivalTime: 29 Mar 2007 21:41:25.0841 (UTC) FILETIME=[006A0410:01C7724B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 > Because there will be a -lot- more lookups, critical to -all- =20 > communications relationships, everywhere. DNS flakiness certainly =20 > can result in service/communications unavailability, but it isn't a =20 > guarantee. I don't see that at all; you use the DNS to find out where the service lives, and then you go knock on the door to see if there is anyone home. It would be no different than the way the DNS works today. =20 Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 17:42: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 1HX2O5-0007HV-DH; Thu, 29 Mar 2007 17:42:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2O3-0007G2-Ut for ram@iab.org; Thu, 29 Mar 2007 17:42:27 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX2O1-0002tP-8Q for ram@iab.org; Thu, 29 Mar 2007 17:42:27 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 29 Mar 2007 14:42:24 -0700 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 l2TLgO8d003900 for ; Thu, 29 Mar 2007 14:42:24 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2TLgOA8025281 for ; Thu, 29 Mar 2007 21:42:24 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <460C3155.6050609@cisco.com> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> <2F3CB446-9DD5-4189-8A42-B25E5A269F61@cisco.com> <20070329213259.GA13108@1-4-5.net> <460C3155.6050609@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0DE5D6A5-8BCF-430E-967B-7A2F6055C787@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 14:42:37 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=874; t=1175204544; x=1176068544; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=Tec4iQUHLZwQdPcbzJ/GAAN0cYxoDYSJvgj3mMLjwHQ=; b=rMEmVbvQREWetTMcZaODJWvflDgXxgAvtwI/qk+8rpEgoqlEAbBM1k46MPyAMzMUzFeCzyYU axDAFdjO7sxHWHhTQIetCQ4HHPPDAE+Q9UYZ4DWRrhwrhfNuIIS4zM89; 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: 7d33c50f3756db14428398e2bdedd581 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 Mar 29, 2007, at 2:36 PM, Russ White wrote: > Which begs the question--is the root of the problem the current > structure of DNS, perhaps? Is it worth looking at something to replace > DNS, rather than something to shim between DNS and IP? If it's DNS or X.500 or LDAP or whatever -completely self-contained within the network infrastructure itself, fine, no problem-. It can't be siloed off to separate general-purpose computers/applicances adminned by groups distinct from the network operations staff, nor can the network operations staff be expected admin separate general- purpose computers or appliances. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 17:45: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 1HX2Qu-0007pr-9b; Thu, 29 Mar 2007 17:45:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2Qt-0007pm-7x for ram@iab.org; Thu, 29 Mar 2007 17:45:23 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX2Qr-0003UD-Jm for ram@iab.org; Thu, 29 Mar 2007 17:45:23 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l2TLjKUp014285; Thu, 29 Mar 2007 13:45:20 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l2TLjKX2014284; Thu, 29 Mar 2007 13:45:20 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 29 Mar 2007 13:45:20 -0800 From: David Meyer To: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Message-ID: <20070329214520.GA14261@1-4-5.net> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> <2F3CB446-9DD5-4189-8A42-B25E5A269F61@cisco.com> <20070329213259.GA13108@1-4-5.net> <460C3155.6050609@cisco.com> <0DE5D6A5-8BCF-430E-967B-7A2F6055C787@cisco.com> Mime-Version: 1.0 In-Reply-To: <0DE5D6A5-8BCF-430E-967B-7A2F6055C787@cisco.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "No wasted time, we're alive today, Churnin up the past, there's no easier way, Time's been between us, a means to an end, G_d it's good to be here walking together my friend" -- srv, Life By The Drop X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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="===============1170098817==" Errors-To: ram-bounces@iab.org --===============1170098817== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >Which begs the question--is the root of the problem the current > >structure of DNS, perhaps? Is it worth looking at something to replace > >DNS, rather than something to shim between DNS and IP? >=20 > If it's DNS or X.500 or LDAP or whatever -completely self-contained =20 > within the network infrastructure itself, fine, no problem-. It =20 > can't be siloed off to separate general-purpose computers/applicances =20 > adminned by groups distinct from the network operations staff, nor =20 > can the network operations staff be expected admin separate general-=20 > purpose computers or appliances. cf. infrastructure ENUM (let's not go there). --dmm --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFGDDNwORgD1qCZ2KcRAnKYAJ9uAOisCNmqBlqt2GyL8dfzIGjW0ACgiB68 ilBR7vA6XkHQK0/AJ1t37gI= =5cC/ -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- --===============1170098817== 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 --===============1170098817==-- From ram-bounces@iab.org Thu Mar 29 17: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 1HX2RI-0007un-LR; Thu, 29 Mar 2007 17:45:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2RH-0007ui-VZ for ram@iab.org; Thu, 29 Mar 2007 17:45:47 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX2RG-0003b7-2a for ram@iab.org; Thu, 29 Mar 2007 17:45:47 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B4AD687331; Thu, 29 Mar 2007 17:45:45 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Incremental Deployment of LISP Message-Id: <20070329214545.B4AD687331@mercury.lcs.mit.edu> Date: Thu, 29 Mar 2007 17:45:45 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: jnc@mercury.lcs.mit.edu 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: David Meyer > "No circular dependencies" -- A long held Internet design principle > dating back to Postel (or maybe before). Minor historical aside: I believe the earliest system to explicitly state (and live by) this concept was the THE operating system of Dijkstra et al: http://en.wikipedia.org/wiki/THE_(operating_system) dating from the mid-60's; it's certainly the paper they made us read in the systems course about this concept. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 17:49: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 1HX2UI-0000vM-T7; Thu, 29 Mar 2007 17:48:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2UH-0000vF-RP for ram@iab.org; Thu, 29 Mar 2007 17:48:53 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX2U4-0004GD-Lt for ram@iab.org; Thu, 29 Mar 2007 17:48:53 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 29 Mar 2007 14:48:39 -0700 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 l2TLmca6002920 for ; Thu, 29 Mar 2007 14:48:39 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2TLmcA8027147 for ; Thu, 29 Mar 2007 21:48:38 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774857@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu><0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com><474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com> <05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774857@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <761E822F-5D0D-47C8-B59C-451DFC7B6AF4@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 14:48:52 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1049; t=1175204919; x=1176068919; c=relaxed/simple; s=sjdkim5002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=xF4wLNpDge4mV64EBMLxO3pPoqJQw6eJjLPkhkKVoew=; b=mD3/OZFUEttL7bglGQ8sjJioGaXelP6bGjD0uHCvkpyqKCjS8wOKR/smrbDoybqFAKDLpD7I BAccfxAHrpNTjIbiyE8rMkCKCOvY80HT6KST8Lkrxk1XZusmWSUuSXCK; Authentication-Results: sj-dkim-5; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Mar 29, 2007, at 2:41 PM, Templin, Fred L wrote: > It would be no different than the > way the DNS works today. It would be in the sense that -routing of packets- would break without it, and a critical dependency for routing packets would for the first time in the history of the Internet be outside the control of network operators, thrust upon people who don't understand and don't want the responsibility in the first place. Also, there's a whole lot of TCP/IP communications which take place which require no DNS lookups at all; for the communications which take place which require DNS, the ratio of packets to DNS lookups is very high, and the amount of dynamism-induced periodic/ongoing DNS lookups is very low. With LISP or a similar proposal, this would change. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 17: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 1HX2Xj-0005U2-3u; Thu, 29 Mar 2007 17:52:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2Xi-0005SR-HH for ram@iab.org; Thu, 29 Mar 2007 17:52:26 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX2Xh-0005Bj-6B for ram@iab.org; Thu, 29 Mar 2007 17:52:26 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l2TLqOOW014663; Thu, 29 Mar 2007 13:52:24 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l2TLqKUx014662; Thu, 29 Mar 2007 13:52:20 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 29 Mar 2007 13:52:20 -0800 From: David Meyer To: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Message-ID: <20070329215220.GA14644@1-4-5.net> References: <05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774857@XCH-NW-7V2.nw.nos.boeing.com> <761E822F-5D0D-47C8-B59C-451DFC7B6AF4@cisco.com> Mime-Version: 1.0 In-Reply-To: <761E822F-5D0D-47C8-B59C-451DFC7B6AF4@cisco.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "No wasted time, we're alive today, Churnin up the past, there's no easier way, Time's been between us, a means to an end, G_d it's good to be here walking together my friend" -- srv, Life By The Drop 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: , Content-Type: multipart/mixed; boundary="===============0510010931==" Errors-To: ram-bounces@iab.org --===============0510010931== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2007 at 02:48:52PM -0700, Roland Dobbins wrote: >=20 > On Mar 29, 2007, at 2:41 PM, Templin, Fred L wrote: >=20 > >It would be no different than the > >way the DNS works today. >=20 > It would be in the sense that -routing of packets- would break =20 > without it, and a critical dependency for routing packets would for =20 > the first time in the history of the Internet be outside the control =20 > of network operators, thrust upon people who don't understand and =20 > don't want the responsibility in the first place. >=20 > Also, there's a whole lot of TCP/IP communications which take place =20 > which require no DNS lookups at all; for the communications which =20 > take place which require DNS, the ratio of packets to DNS lookups is =20 > very high, and the amount of dynamism-induced periodic/ongoing DNS =20 > lookups is very low. With LISP or a similar proposal, this would =20 > change. FWIW, LISP 2 (the DNS variant) is most likely an non-starter (as Dino mentioned) for all of the reasons we've been discussing here. As I understandn it, LISP 2 was included for completeness. --dmm --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFGDDUUORgD1qCZ2KcRApT6AJ9eREbG8dycdXizlguWgdFXnVTbUACcDpUe M2PMcRY12IAzwysngTWOYPA= =pcRq -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- --===============0510010931== 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 --===============0510010931==-- From ram-bounces@iab.org Thu Mar 29 18:06:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2jq-0007s5-Q5; Thu, 29 Mar 2007 18:04:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2jo-0007rx-TS for ram@iab.org; Thu, 29 Mar 2007 18:04:56 -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 1HX2jm-0002Dr-Ip for ram@iab.org; Thu, 29 Mar 2007 18:04:56 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2TM4pef013305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Mar 2007 15:04:51 -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 l2TM4p4V021324; Thu, 29 Mar 2007 15:04:51 -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 l2TM4m85021198; Thu, 29 Mar 2007 15:04:51 -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); Thu, 29 Mar 2007 15:04: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] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 15:04:48 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774858@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <761E822F-5D0D-47C8-B59C-451DFC7B6AF4@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: AcdyTCjVBXWvmLU4RuqJOMsQybgtBgAAb4jA References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu><0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com><474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com><05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774857@XCH-NW-7V2.nw.nos.boeing.com> <761E822F-5D0D-47C8-B59C-451DFC7B6AF4@cisco.com> From: "Templin, Fred L" To: "Roland Dobbins" , X-OriginalArrivalTime: 29 Mar 2007 22:04:49.0094 (UTC) FILETIME=[44D16E60:01C7724E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 =20 > -----Original Message----- > From: Roland Dobbins [mailto:rdobbins@cisco.com]=20 > Sent: Thursday, March 29, 2007 2:49 PM > To: ram@iab.org > Subject: Re: [RAM] Incremental Deployment of LISP >=20 >=20 > On Mar 29, 2007, at 2:41 PM, Templin, Fred L wrote: >=20 > > It would be no different than the > > way the DNS works today. >=20 > It would be in the sense that -routing of packets- would break =20 > without it, and a critical dependency for routing packets would for =20 > the first time in the history of the Internet be outside the control =20 > of network operators, thrust upon people who don't understand and =20 > don't want the responsibility in the first place. When the DNS is up, the situation would be *way better* than for today since countless IPv6 services would be available. When the DNS is down, the situation would be no worse than for today since IPv4 services would still be reachable. But, when is the DNS ever down? Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 18:12: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 1HX2qb-0003EZ-CK; Thu, 29 Mar 2007 18:11:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2qZ-0003ER-8D for ram@iab.org; Thu, 29 Mar 2007 18:11:55 -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 1HX2qJ-0004n4-UE for ram@iab.org; Thu, 29 Mar 2007 18:11:55 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2007 15:11:40 -0700 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 l2TMBdbM010157 for ; Thu, 29 Mar 2007 15:11:39 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2TMBdA8003095 for ; Thu, 29 Mar 2007 22:11:39 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774858@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu><0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com><474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com><05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774857@XCH-NW-7V2.nw.nos.boeing.com> <761E822F-5D0D-47C8-B59C-451DFC7B6AF4@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774858@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <572275AE-D96D-46AA-8469-2B5C663B19F7@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 15:11:52 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=593; t=1175206299; x=1176070299; c=relaxed/simple; s=sjdkim5002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=y1kxJM3lOkp3sXo0AKkFrtg6NMdw0UE2rjyAo1vbpiY=; b=Xlz8HmUr1pJPo4rCSsaHSOifPE1QNdMGnZKN8ywFvlY0ktpsFdXYP+tx80T8eOUAzS2H0hbb 9XeOq6Hc0GDfqQaZOQVGHfOg3LLZCjMD81fSOzodnH5b/RbboKvZpi3o; Authentication-Results: sj-dkim-5; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Mar 29, 2007, at 3:04 PM, Templin, Fred L wrote: > But, > when is the DNS ever down? All the time, in different localities (for widely varying values of 'locality'). Anyways, this issue has been beaten to death, as dmm indicated. In terms of LISP, it only applies to LISP v2, which was included mainly for the sake of completeness. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 18:17: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 1HX2v9-0006yp-N6; Thu, 29 Mar 2007 18:16:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2v7-0006yj-Ib for ram@iab.org; Thu, 29 Mar 2007 18:16:37 -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 1HX2v6-0006ua-A1 for ram@iab.org; Thu, 29 Mar 2007 18:16:37 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2TMGZW1019104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Mar 2007 15:16:35 -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 l2TMGYSh024062; Thu, 29 Mar 2007 17:16:34 -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 l2TMGYuj024047; Thu, 29 Mar 2007 17:16:34 -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); Thu, 29 Mar 2007 15:16:30 -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] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 15:16:30 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774859@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <572275AE-D96D-46AA-8469-2B5C663B19F7@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: AcdyT2SGpQaEJUxpR127lwcD6z14SwAAC4cw References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu><0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com><474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com><05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774857@XCH-NW-7V2.nw.nos.boeing.com><761E822F-5D0D-47C8-B59C-451DFC7B6AF4@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774858@XCH-NW-7V2.nw.nos.boeing.com> <572275AE-D96D-46AA-8469-2B5C663B19F7@cisco.com> From: "Templin, Fred L" To: "Roland Dobbins" , X-OriginalArrivalTime: 29 Mar 2007 22:16:31.0228 (UTC) FILETIME=[E75293C0:01C7724F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 > All the time, in different localities (for widely varying values of =20 > 'locality'). I think the way you define "locality" is the crux of the matter; if you mean within an enterprise/site, then you can just use IPv6 routing no problem. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 18:23: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 1HX2zv-0000nk-Qr; Thu, 29 Mar 2007 18:21:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX2zu-0000nZ-3S for ram@iab.org; Thu, 29 Mar 2007 18:21:34 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HX2zg-0008C1-82 for ram@iab.org; Thu, 29 Mar 2007 18:21:34 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 29 Mar 2007 15:21:19 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l2TMLJqd027664 for ; Thu, 29 Mar 2007 15:21:19 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2TMLIwn012510 for ; Thu, 29 Mar 2007 22:21:19 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774859@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu><0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com><474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com><05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774857@XCH-NW-7V2.nw.nos.boeing.com><761E822F-5D0D-47C8-B59C-451DFC7B6AF4@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774858@XCH-NW-7V2.nw.nos.boeing.com> <572275AE-D96D-46AA-8469-2B5C663B19F7@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774859@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C23C944-2F0F-4C26-9299-EDE47D2434F6@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 15:21:32 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=715; t=1175206879; x=1176070879; c=relaxed/simple; s=sjdkim6002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=tpe14DTY0YglrdJRerTuxtE2yyQ+rZqudP501Wu3y3w=; b=dVmtIGKf2a3iQMVYJYM0xUMAArKOLnto/y1MROZemvlBA1rd8HBNcq5jgkVl26dlpzoi+52Q /8CDJt9LIxPbFdn5XRG4FYqTSDmqycerxs8D9Rr3NMI6oCOlUWdOG5ei; Authentication-Results: sj-dkim-6; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Mar 29, 2007, at 3:16 PM, Templin, Fred L wrote: > I think the way you define "locality" is the crux of the > matter; if you mean within an enterprise/site, then you > can just use IPv6 routing no problem. That's situationally-specific, too. But this problem aside, the siloing/externality issue is a showstopper, even if the other issues weren't of consequence. I'm not going to comment on this issue further, as I don't want to keep spamming the list. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 18:27: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 1HX34y-0004jU-EB; Thu, 29 Mar 2007 18:26:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX34w-0004jP-Pk for ram@iab.org; Thu, 29 Mar 2007 18:26:46 -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 1HX34u-0001Cv-H6 for ram@iab.org; Thu, 29 Mar 2007 18:26:46 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2TMQdwF023611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Mar 2007 15:26:39 -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 l2TMQdHj002947; Thu, 29 Mar 2007 15:26:39 -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 l2TMQcuw002908; Thu, 29 Mar 2007 15:26:39 -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); Thu, 29 Mar 2007 15:26:36 -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] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 15:26:35 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177485A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <1C23C944-2F0F-4C26-9299-EDE47D2434F6@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: AcdyUM/twjjlv36wTpSF6EbfSYaIbgAADV5Q References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu><0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com><474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com><05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774857@XCH-NW-7V2.nw.nos.boeing.com><761E822F-5D0D-47C8-B59C-451DFC7B6AF4@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774858@XCH-NW-7V2.nw.nos.boeing.com><572275AE-D96D-46AA-8469-2B5C663B19F7@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774859@XCH-NW-7V2.nw.nos.boeing.com> <1C23C944-2F0F-4C26-9299-EDE47D2434F6@cisco.com> From: "Templin, Fred L" To: "Roland Dobbins" , X-OriginalArrivalTime: 29 Mar 2007 22:26:36.0907 (UTC) FILETIME=[5055DBB0:01C77251] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 > That's situationally-specific, too. But this problem aside, the =20 > siloing/externality issue is a showstopper, even if the other issues =20 > weren't of consequence. > > I'm not going to comment on this issue further, as I don't want to =20 > keep spamming the list. That's fine with me, but I still don't see any problem. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Mar 29 19:06: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 1HX3fg-0006fv-SZ; Thu, 29 Mar 2007 19:04:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX3ff-0006cb-0o for ram@iab.org; Thu, 29 Mar 2007 19:04:43 -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 1HX3fd-0007i9-Ka for ram@iab.org; Thu, 29 Mar 2007 19:04:43 -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 l2TN4SfH009292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Mar 2007 18:04:29 -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 l2TN4Ssj004666; Thu, 29 Mar 2007 16:04:28 -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 l2TN4PiK004579; Thu, 29 Mar 2007 16:04:28 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 16:04:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RAM] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 16:04:26 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584EA5@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: AcdyPhGv+oiEkrAxRKqpAPgBGb4+nQAFfuyg References: From: "Fleischman, Eric" To: , , X-OriginalArrivalTime: 29 Mar 2007 23:04:28.0124 (UTC) FILETIME=[9A1611C0:01C77256] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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="===============0984310291==" Errors-To: ram-bounces@iab.org This is a multi-part message in MIME format. --===============0984310291== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77256.996A5D8A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77256.996A5D8A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are doubtlessly many ways in which LISP can be implemented, with certain approaches being considerably simpler than others. =20 Here's how I see it: 1) The transport network (i.e., the Internet comprised of ISPs) handles transport (Internet) routing. The ISPs providing those routing services are "well known". 2) When an entity (e.g., a corporate AS) wishes to connect to that transport network (e.g., the Internet), it contacts one or more of those well-known ISPs of its choice 3) The ISPs and entity wishing to be Internet-connected negotiate (via any mechanism of their choice) to determine the relevant policy and business issues associated with that business arrangement. Among those issues is the identification of the Points-of-presence between the corporate AS (for example) and the ISP. This forms an address pairing mapping between an ISP tunnel endpoint within the transport network (i.e., the Internet) and the corporate AS network.=20 4) The ISP reports that address pairing to the DNS infrastructure used by the transport network (e.g., the Internet) that is readable by all. =20 Please notice the complete absence of any logic or procedural circularity at any point within this process. "Discovery" is handled by the ISP in accordance with the business relationship established with the entity it is supporting (e.g., a corporate AS). =20 HeinerHummel@aol.com [mailto:HeinerHummel@aol.com] wrote=20 > "Saying where some user is" and "communicating, I have reachability to this or that" =20 > relates to the same, which is, at which node you may find that guy. =20 > How to get there is of course a different thing.=20 =20 > I think we don't have that different opinions as it may look like, right ? =20 =20 ------_=_NextPart_001_01C77256.996A5D8A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There are = doubtlessly=20 many ways in which LISP can be implemented, with certain approaches = being=20 considerably simpler than others.
 
Here's how = I see=20 it:
1) =  The transport=20 network (i.e., the Internet comprised of ISPs) handles transport = (Internet)=20 routing. The ISPs providing those routing services are "well=20 known".
2) =  When an entity=20 (e.g., a corporate AS) wishes to connect to that transport network = (e.g., the=20 Internet), it contacts one or more of those well-known ISPs of its=20 choice
3) =  The ISPs and=20 entity wishing to be Internet-connected negotiate (via any mechanism of = their=20 choice) to determine the relevant policy and business issues associated = with=20 that business arrangement. Among those issues is the identification of=20 the Points-of-presence between the corporate AS (for example) = and the=20 ISP. This forms an address pairing mapping between an ISP tunnel = endpoint within=20 the transport network (i.e., the Internet) and the corporate AS=20 network. 
4) =  The ISP reports=20 that address pairing to the DNS infrastructure used by the transport = network=20 (e.g., the Internet) that is readable by all.
 
Please = notice the=20 complete absence of any logic or procedural circularity at any point = within this=20 process. "Discovery" is handled by the ISP in accordance with the = business=20 relationship established with the entity it is supporting (e.g., a = corporate=20 AS).

 
HeinerHummel@aol.com=20 [mailto:HeinerHummel@aol.com]  wrote 
 > "Saying where some user is" and=20 "communicating, I have reachability to this or that"  
>  relates to the same, which = is, at=20 which node you may find that guy.
 
 > How to get = there is=20 of course a different thing.
 
 > I think we = don't have=20 that different opinions as it may look like, right ?
 
 
 ------_=_NextPart_001_01C77256.996A5D8A-- --===============0984310291== 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 --===============0984310291==-- From ram-bounces@iab.org Thu Mar 29 20:14: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 1HX4iR-00013i-3J; Thu, 29 Mar 2007 20:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX4iP-00013c-MA for ram@iab.org; Thu, 29 Mar 2007 20:11:37 -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 1HX4iO-0000xO-CS for ram@iab.org; Thu, 29 Mar 2007 20:11:37 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2U0BXad000266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Mar 2007 17:11:33 -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 l2U0BWcJ023876; Thu, 29 Mar 2007 17:11:32 -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 l2U0BWMJ023869; Thu, 29 Mar 2007 17:11:32 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 17:11:32 -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] Incremental Deployment of LISP Date: Thu, 29 Mar 2007 17:11:31 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <761E822F-5D0D-47C8-B59C-451DFC7B6AF4@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: AcdyTCklhTsw9GJrRoq4qIKRN5gCtQAC3SdA References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu><0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com><474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com><05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774857@XCH-NW-7V2.nw.nos.boeing.com> <761E822F-5D0D-47C8-B59C-451DFC7B6AF4@cisco.com> From: "Fleischman, Eric" To: , X-OriginalArrivalTime: 30 Mar 2007 00:11:32.0472 (UTC) FILETIME=[F8C8D780:01C7725F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 From: Roland Dobbins [mailto:rdobbins@cisco.com]=20 >It would be in the sense that -routing of packets- would break without it,=20 >and a critical dependency for routing packets would for the first time in=20 >the history of the Internet be outside the control of network operators,=20 >thrust upon people who don't understand and don't want the responsibility=20 >in the first place. Speaking as a (very) large end user representing what I (perhaps incorrectly) expect the ISPs supporting us to do, I believe that this is not a problem for the following reason: We negotiate our Internet service with our ISPs. This is an involved process that is not done overnight, to say the least. Each ISP provides ingress and egress paths to the Internet for us. The disproportionate percentage of our traffic goes to a finite number (let's say a few hundred -- but this number is not relevant) of remote ASes via a small set of ISP-provided routers that are connected to a small-set of POP routers that we provide. These ISP-provided routers will not be looking up DNS entries at any point because the latency involved with DNS lookups could not support the very high data rates that they have committed to support in their business agreements with us. For this reason, I expect that the ISPs will periodically map the Remote AS-to Remote-Internet-tunnel-endpoint relationships contained in the then current DNS tables (from the perspective of their position within the Internet (e.g., in regards to load-balancing and multi-homing and traffic engineering connections in accordance with our agreements together)) via a mechanism of their choice. This calculation will create a database that they will then load into an appropriate cache within their POP routers. This cache will contain the calculations for ***entire Internet DNS table*** because they must not presume that all of our traffic will always remain limited to the few hundred remote ASes that we primarily deal with. I further presume that only deltas (changes) will need to be loaded and that the cache updates will not require the routers to go off-line at any point. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 01:28: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 1HX9av-0003Eo-3L; Fri, 30 Mar 2007 01:24:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HX9ao-00036f-VK for ram@iab.org; Fri, 30 Mar 2007 01:24:11 -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 1HX9ao-00005f-Ef for ram@iab.org; Fri, 30 Mar 2007 01:24:06 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l2U5NcHL022843; Fri, 30 Mar 2007 08:23:38 +0300 Date: Fri, 30 Mar 2007 08:23:38 +0300 (EEST) From: Pekka Savola To: Dino Farinacci In-Reply-To: <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> Message-ID: References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.1/2962/Thu Mar 29 21:39:44 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS 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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Margaret Wasserman , ram@iab.org Subject: [RAM] ICMP error dependency in LISP (was: Incremental Deployment of LISP) 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 Thu, 29 Mar 2007, Dino Farinacci wrote: > In LISP 1 and 1.5, when the inner DA is copied to the outer DA in the ITR and > there is no ETR, the destination host will return an ICMP Protocol > Unreachable message. What are the fallbacks if: a) A transit router has no route to the destination for whatever reasons, but does have a default discard route and does not generate ICMP errors for packets which match that route? [personally I don't think this is necessarily a very serious problem because this happens with current routing as well] b) the destination implementation just doesn't send out Protocol Unreachables for unknown protocols? (not sure how common this is) c) the destination (host?) is currently rate-limiting ICMP error generation (mandated by the specification) and the ICMP error is not sent? [e.g., this is why you couldn't build this ICMP error generation dependency between two routers either; routers are actually even more busy with their ICMP error generation and more likely to not send the error] d) some poor firewall or ACL filters out the ICMP message at the ICMP originator's domain, in transit, or at the recipient's domain? e) the ICMP error gets lost in the network (transient routing loop, congestion, etc.). ICMP delivery is after all unreliable. While participating in Transport Area working groups (e.g., TCPM) I've had an.. opportunity to hear rants about ICMP, for example, that it should be considered completely optional and anything that requires ICMP to work is broken; at best, ICMP should be an optimization mechanism. I'm not sure if I completely agree with these, but for sure I wouldn't built a system that had a very strong requirement for ICMP error generation and propagation. -- 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 Fri Mar 30 05:05: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 1HXD0D-0000pl-1w; Fri, 30 Mar 2007 05:02:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXD0B-0000o1-8H for ram@iab.org; Fri, 30 Mar 2007 05:02:31 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXD09-00008M-Q9 for ram@iab.org; Fri, 30 Mar 2007 05:02:31 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AF12F114CEF; Fri, 30 Mar 2007 11:02:28 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp02.uc3m.es (Postfix) with ESMTP id 92AE3114A60; Fri, 30 Mar 2007 11:02:28 +0200 (CEST) In-Reply-To: <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Fri, 30 Mar 2007 11:04:55 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 El 29/03/2007, a las 19:36, Dino Farinacci escribi=F3: >>> If the ISP needs the mappings it could get it, but according to the=20= >>> draft, the TE-ITR will look at outer headers and if the site ITR had=20= >>> prepended a header, the outer DA at the TE-ITR is a locator address. >>> >> >> ok, so in this case the intermediate ISP should know that two (or=20 >> more) locators are equivalent (i.e. they are associated to the same=20= >> identifier (or potentially set of identifiers)), right? > > I don't know what you mean. The TE-ITR only needs to route on the=20 > outer DA so it would only need a FIB route that the DA would match. > agree the question is where does the information about the equivalent=20 destinations comes from >>> In the ISP's case, an equivalence class of prefixes will be=20 >>> associated with the TE-ITR's encapsulation. And this would be mostly=20= >>> static in nature. >>> >> >> So, if i understand correctly an equivalence class of locators are=20 >> all the locators associated to an identifier (or a set of=20 >> identifiers). In particular, in the case of a multihomed site, an=20 >> equivalence class is the set of RLOC (i.e. of PA addresses) that are=20= >> associated to the site, right? > > No, it is the same way an ISP routes data for a set of prefixes across=20= > an IGP shortcut MPLS LSP. > > This is the same problem just using an IP tunnel to move large number=20= > of flows from going to one egress point to another. > right, so what is the benefit added by LISP? I mean you can do tunnels to change large amount of flows within a set=20= of ISPs today, without LISP right? I understood that the benefit provided by LISP is that you would be=20 able to do this autmatically because the intermediate ISP would be able=20= to learn the equivalent classes of locators automatically without=20 needing to do any manual configuration, but it seems this is not the=20 case... Regards, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 06:25: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 1HXEGK-00021T-Ld; Fri, 30 Mar 2007 06:23:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXEGK-00021O-4p for ram@iab.org; Fri, 30 Mar 2007 06:23:16 -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 1HXEGI-0003vc-Og for ram@iab.org; Fri, 30 Mar 2007 06:23:16 -0400 Received: from terminus.icann-lisboa.pt (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l2UA9061018503; Fri, 30 Mar 2007 02:09:11 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.icann-lisboa.pt (PGP Universal service); Fri, 30 Mar 2007 11:22:38 +0100 X-PGP-Universal: processed; by terminus.icann-lisboa.pt on Fri, 30 Mar 2007 11:22:38 +0100 In-Reply-To: <20070329195425.A5F4C87324@mercury.lcs.mit.edu> References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP Date: Fri, 30 Mar 2007 11:22:27 +0100 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Mar 29, 2007, at 8:54 PM, Noel Chiappa wrote: >> The DNS won't work, and deploying some other infrastructure .. to >> handle lookups is a nonstarter, IMHO. > > OK, so what will work? :-) More of what we've already got, because > anything > else is too painful to deploy? At one extreme, there is the pull model. The DNS is an example. The other extreme is a push model, where the mapping is flooded to the entities that are doing the mapping. There are a number of protocols that do this, that I'm sure you're aware of. Both extremes have advantages and disadvantages. Assertions that a push model like the DNS won't work because of the way the DNS has historically been implemented are, of course, specious. The DNS protocol is a relatively lightweight protocol that we understand fairly well (warts and all). I'm sure someone can come up with another protocol that implements a identifier to locator mapping by fetching the data on demand, but I suspect the result will look a lot like the DNS (hopefully without the warts). The assertions that something like the DNS won't work because of circular dependencies are also wrong, since routing could depend on a subset of directory and the directory would depend on a different subset of routing. For example, in a simple model where you have 2 different non-intersecting addressing universes (call them "identifiers" and "locators" just for fun), the mapping service devices would be exclusively numbered in the locator space. My suspicion is that a pull model is the most likely to provide the amount of information hiding (of a sort) necessary for us to get to the level of scalability we're looking for, and we'll just have to eat the initial RTT latency hit. It is probably worth remembering that the edge is already used to a similar latency hit, after all, very few people put IP addresses as the URL in their browsers... Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 06:27: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 1HXEJz-0003nA-LC; Fri, 30 Mar 2007 06:27:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXEJy-0003hy-6X for ram@iab.org; Fri, 30 Mar 2007 06:27:02 -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 1HXEJw-0004da-QT for ram@iab.org; Fri, 30 Mar 2007 06:27:02 -0400 Received: from terminus.icann-lisboa.pt (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l2UADT61018515; Fri, 30 Mar 2007 02:13:31 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.icann-lisboa.pt (PGP Universal service); Fri, 30 Mar 2007 11:26:59 +0100 X-PGP-Universal: processed; by terminus.icann-lisboa.pt on Fri, 30 Mar 2007 11:26:59 +0100 In-Reply-To: <05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com> References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu> <0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com> <474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com> <05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <44231989-E7CA-41B9-BF11-371FD0B4C618@virtualized.org> From: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP Date: Fri, 30 Mar 2007 11:26:56 +0100 To: Roland Dobbins X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 On Mar 29, 2007, at 10:25 PM, Roland Dobbins wrote: > Because there will be a -lot- more lookups, critical to -all- > communications relationships, everywhere. DNS flakiness certainly > can result in service/communications unavailability, but it isn't a > guarantee. > > And the DNS contains a mess of unpatched, insecure hosts which > nobody maintains - this is true of routers and other network > infrastructure too, to some extent, but less than the DNS, IMHO, > and, unlike DNS servers, these devices will -have- to be upgraded > to work with the new system. Please make a distinction between the DNS as a protocol and the DNS as it has been implemented. The DNS protocol is a relatively lightweight primarily UDP-based protocol that can fall back to TCP in certain circumstances. Blaming that protocol for the sins of poor implementations seems a bit silly. Thanks, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 06:43:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXEZ5-0000n1-6a; Fri, 30 Mar 2007 06:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXEZ4-0000mw-Cj for ram@iab.org; Fri, 30 Mar 2007 06:42:38 -0400 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXEZ2-0007nL-Uh for ram@iab.org; Fri, 30 Mar 2007 06:42:38 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l2UAgZCF073266 for ; Fri, 30 Mar 2007 10:42:35 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l2UAgZJk2474020 for ; Fri, 30 Mar 2007 11:42:35 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l2UAgZSa005818 for ; Fri, 30 Mar 2007 11:42:35 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l2UAgZE2005812; Fri, 30 Mar 2007 11:42:35 +0100 Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA277378; Fri, 30 Mar 2007 12:42:33 +0200 Message-ID: <460CE997.9010902@zurich.ibm.com> Date: Fri, 30 Mar 2007 12:42:31 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] what we should be working on References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <8C9386510C30DCC-1780-504F@FWM-M10.sysops.aol.com> <43298230-F92B-426C-8735-84FA78202CF6@muada.com> <7CF3DDEA-74DF-4117-BD00-7BDF48A21E6D@cisco.com> In-Reply-To: <7CF3DDEA-74DF-4117-BD00-7BDF48A21E6D@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) 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 (in catch up mode) On 2007-03-20 08:31, Tony Li wrote: > > On Mar 20, 2007, at 8:26 AM, Iljitsch van Beijnum wrote: > >> On 20-mrt-2007, at 6:52, Tony Li wrote: >> >>> Raising the average packet size would increase jitter. This may well >>> be irrelevant at GigE speeds, but at lower speeds could become >>> significant. Someone should work the figures... >> >> How much jitter is acceptable? > > > This is also all over the map and is really the domain of our VOIP and > video brethren. I'll let them speak for themselves. I'm not one of them, but I believe the answer is that on links where this is an issue you will run a couple of diffserv classes, and in the class used for real time traffic the packet sizes will be uniform and an EF queuing discipline will manage jitter. I would be shocked if we needed to do this on underloaded GigE access links or on provider backbones. There, an MTU that readily accommodates encapsulation overhead seems appropriate. Brian > >> >> It would also be helpful to know the amount of buffering that happens >> in routers and switches, but that seems to be all over the map. > > > Correct. It very much depends on make and model. There is no hard and > fast standard. > > 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 Fri Mar 30 07:36: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 1HXFMH-0007wp-M4; Fri, 30 Mar 2007 07:33:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXFMG-0007wj-OO for ram@iab.org; Fri, 30 Mar 2007 07:33:28 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXFMG-0008Ia-GJ for ram@iab.org; Fri, 30 Mar 2007 07:33:28 -0400 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [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 l2UBWOlC050627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Mar 2007 13:32:25 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774858@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu><0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com><474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com><05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774857@XCH-NW-7V2.nw.nos.boeing.com> <761E822F-5D0D-47C8-B59C-451DFC7B6AF4@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774858@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <670F79D7-3243-4C16-9411-8DAD808F2392@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Incremental Deployment of LISP Date: Fri, 30 Mar 2007 13:32:51 +0200 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=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: 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 30-mrt-2007, at 0:04, Templin, Fred L wrote: > When the DNS is up, the situation would be *way better* than > for today since countless IPv6 services would be available. > When the DNS is down, the situation would be no worse than > for today since IPv4 services would still be reachable. But, > when is the DNS ever down? I don't think an IPv6-only solution is an attractive option... But let me answer your question with a question: why don't firewalls put DNS names rather than IP addresses and ranges in their configurations? And arguably, a "jack up" encapsulation box would be more critical than a firewall. With a firewall, you may be able to filter on other stuff if a DNS lookup fails, which isn't much of an option after a failed locator lookup. Iljitsch _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 08:24:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXG8P-0004UK-J3; Fri, 30 Mar 2007 08:23:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXG8N-0004UC-KL for ram@iab.org; Fri, 30 Mar 2007 08:23:11 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXG8N-0000jf-6X for ram@iab.org; Fri, 30 Mar 2007 08:23:11 -0400 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [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 l2UCMeAI051547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Mar 2007 14:22:40 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <460CE997.9010902@zurich.ibm.com> References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <8C9386510C30DCC-1780-504F@FWM-M10.sysops.aol.com> <43298230-F92B-426C-8735-84FA78202CF6@muada.com> <7CF3DDEA-74DF-4117-BD00-7BDF48A21E6D@cisco.com> <460CE997.9010902@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <86C472C7-285F-4920-9CEA-448D43DCCA0C@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] what we should be working on Date: Fri, 30 Mar 2007 14:23:07 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=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: 4d87d2aa806f79fed918a62e834505ca 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 30-mrt-2007, at 12:42, Brian E Carpenter wrote: >>> How much jitter is acceptable? >> This is also all over the map and is really the domain of our VOIP >> and video brethren. I'll let them speak for themselves. > I'm not one of them, but I believe the answer is that on links > where this is an issue you will run a couple of diffserv classes, > and in the class used for real time traffic the packet sizes will > be uniform and an EF queuing discipline will manage jitter. I would > be shocked if we needed to do this on underloaded GigE access links > or on provider backbones. There, an MTU that readily accommodates > encapsulation overhead seems appropriate. After thinking about this for a bit, my conclusion is that there are two issues: the up/downlink between an end-user and a service provider, and the stuff in the middle. The up/downlink is typically (but not always) the bottleneck bandwidth-wise and most likely to see congestion. On the sending side, it should be easy enough to use a queuing mechanism that gives priority to real-time traffic (with or without diffserv). On the receiving side this is more difficult, because the queuing is under the control of the ISP there. But the receiving side has the option to stick to standard packet sizes if and when needed so I don't think this is a show stopper. So the problem we have to consider here is just head of line blocking by one extra large packet. This is 1.2 ms for 1500 bytes at 10 Mbps, so even at that speed, a moderate increase is possible and at 100 Mbps or more, this isn't an issue at all. On intra- and inter-ISP links we can probably not assume smart queuing. First of all, AFAIK, most ISPs simply don't use it today, and secondly, because this requires relatively deep packet inspection or trusting diffserv code points set by customers and/or other ISPs. Although most ISP links are fast (especially the jumbo frame capable ones), the problem is that there can be a lot of them, so the jitter gets to build up along the path. I'm thinking something like 1 - 2 ms of extra jitter per hop would likely be acceptable. At Gbps speeds that's 120 to 250 kilobytes that can be buffered, or 13 to 26 packets for 9000 byte packets. However, average packet sizes are a lot smaller. The figure I've seen most is 500 bytes. If we assume (for simplicity) that's an average of 70% 64- byte packets and 30% 1500-byte packets, then a similar mix with 9000- byte packets would result in an average packet size of 2750 bytes, which should be a safe upper limit. This allows for 45 - 90 packet buffers. By the way, it only takes 25% of the 1500-byte packets = 7% of all packets to become 9000 bytes to double the average packet size to 1000 bytes. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 09:23:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXH3p-00005W-RI; Fri, 30 Mar 2007 09:22:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXH3o-00005L-43 for ram@iab.org; Fri, 30 Mar 2007 09:22:32 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXH3m-0003pB-RZ for ram@iab.org; Fri, 30 Mar 2007 09:22:32 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 7ED341C0104; Fri, 30 Mar 2007 15:22:30 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 793CD1C00FD; Fri, 30 Mar 2007 15:22:29 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 6C5BC58ED21; Fri, 30 Mar 2007 15:22:29 +0200 (CEST) Date: Fri, 30 Mar 2007 15:22:29 +0200 From: Stephane Bortzmeyer To: Iljitsch van Beijnum Message-ID: <20070330132229.GB23969@nic.fr> References: <761E822F-5D0D-47C8-B59C-451DFC7B6AF4@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774858@XCH-NW-7V2.nw.nos.boeing.com> <670F79D7-3243-4C16-9411-8DAD808F2392@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <670F79D7-3243-4C16-9411-8DAD808F2392@muada.com> 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ram@iab.org Subject: [RAM] Re: Incremental Deployment of LISP 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 Fri, Mar 30, 2007 at 01:32:51PM +0200, Iljitsch van Beijnum wrote a message of 25 lines which said: > But let me answer your question with a question: why don't firewalls > put DNS names rather than IP addresses and ranges in their > configurations? Some do (IOS, Linux' netfilter, BSD's pf). It is typically regarded as a bad idea for security (at least until DNSSEC comes) but it works. We just miss a way to honor the DNS TTL in these configurations. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 09:23:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXH25-0007AW-9T; Fri, 30 Mar 2007 09:20:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXH23-0007AL-NK for ram@iab.org; Fri, 30 Mar 2007 09:20:43 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXH20-0003Sp-6J for ram@iab.org; Fri, 30 Mar 2007 09:20:43 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 9D5021C0104 for ; Fri, 30 Mar 2007 15:20:29 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 995CF1C00FD for ; Fri, 30 Mar 2007 15:20:29 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 972F458ED21 for ; Fri, 30 Mar 2007 15:20:29 +0200 (CEST) Date: Fri, 30 Mar 2007 15:20:29 +0200 From: Stephane Bortzmeyer To: ram@iab.org Message-ID: <20070330132029.GA23969@nic.fr> References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu> <0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com> <474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com> <05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com> <44231989-E7CA-41B9-BF11-371FD0B4C618@virtualized.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44231989-E7CA-41B9-BF11-371FD0B4C618@virtualized.org> 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [RAM] The DNS? Which DNS? (Was: Incremental Deployment of LISP 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 Fri, Mar 30, 2007 at 11:26:56AM +0100, David Conrad wrote a message of 28 lines which said: > >And the DNS contains a mess of unpatched, insecure hosts which > >nobody maintains - this is true of routers and other network > >infrastructure too, to some extent, but less than the DNS, IMHO, > >and, unlike DNS servers, these devices will -have- to be upgraded > >to work with the new system. > > Please make a distinction between the DNS as a protocol and the DNS > as it has been implemented. And also please make a distinction between the protocol, the implementation, and the social infrastructure which, today, operates it. Roland Dobbins said: > But the entire workable solution has to be within the realm of the > network infrastructure, there can't be any dependencies upon > sysadmin groups, etc., because of the silos (both natural and > unnatural) in which the relevant skillsets and responsibilities and > interests of these groups seem to pretty much universally reside. You can still use the DNS, the protocol and may be even the DNS, the software, without relying on the social infrastructure (ICANN, the registries, the name server operators). For instance, we could ask the IANA for a new DNS class (currently, IN is the only one in wide use, CH being the closest second), set up a new root which will depend only on the operator community (may be through the RIRs) and then happily use the DNS protocol and the DNS implementations, in a "restricted" environment (much more controlled than the DNS as it is today). This would avoid reinventing a mapping protocol which, as David Conrad said, would probably be very close from the DNS. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 09:39: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 1HXHJj-0005X1-9T; Fri, 30 Mar 2007 09:38:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXHJh-0005Wq-He for ram@iab.org; Fri, 30 Mar 2007 09:38:57 -0400 Received: from web58714.mail.re1.yahoo.com ([66.196.100.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HXHJf-00072v-IA for ram@iab.org; Fri, 30 Mar 2007 09:38:57 -0400 Received: (qmail 61889 invoked by uid 60001); 30 Mar 2007 13:32:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=s87lkVfQFzTdC3VTjZOUz6pTvJ7lcke7PHzoVSBOnNlXaGlAn18gjBtIKM9c0WKNPalH8CYYBdCqoOoLyWSiK89WUhoiWNJf8bf9qoHkDQXfnAB/HJeR0vtE7pF7W+kW6DCq6NPRrPxJei9zYNl8WeeRMroYqBpM2RFYmETQNCg=; X-YMail-OSG: hK.Wd1gVM1mkkaW689HDA28PXG5xjWoABeilqKYy9HsyKwUJ.23jb6sUXmugP3672g-- Received: from [207.107.50.100] by web58714.mail.re1.yahoo.com via HTTP; Fri, 30 Mar 2007 06:32:14 PDT Date: Fri, 30 Mar 2007 06:32:14 -0700 (PDT) From: Peter Sherbin Subject: RE: [RAM] Incremental Deployment of LISP To: "Fleischman, Eric" , rdobbins@cisco.com, ram@iab.org In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <22000.61535.qm@web58714.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Speaking as a (large) ISP I hear a client wanting a sort of a private network with a kind of a class of service at price of a shared best effort bandwidth. TANSTAFL :) Thanks, Peter --- "Fleischman, Eric" wrote: > From: Roland Dobbins [mailto:rdobbins@cisco.com] > >It would be in the sense that -routing of packets- would break without > it, > >and a critical dependency for routing packets would for the first time > in > >the history of the Internet be outside the control of network > operators, > >thrust upon people who don't understand and don't want the > responsibility > >in the first place. > > Speaking as a (very) large end user representing what I (perhaps > incorrectly) expect the ISPs supporting us to do, I believe that this is > not a problem for the following reason: > > We negotiate our Internet service with our ISPs. This is an involved > process that is not done overnight, to say the least. Each ISP provides > ingress and egress paths to the Internet for us. The disproportionate > percentage of our traffic goes to a finite number (let's say a few > hundred -- but this number is not relevant) of remote ASes via a small > set of ISP-provided routers that are connected to a small-set of POP > routers that we provide. These ISP-provided routers will not be looking > up DNS entries at any point because the latency involved with DNS > lookups could not support the very high data rates that they have > committed to support in their business agreements with us. For this > reason, I expect that the ISPs will periodically map the Remote AS-to > Remote-Internet-tunnel-endpoint relationships contained in the then > current DNS tables (from the perspective of their position within the > Internet (e.g., in regards to load-balancing and multi-homing and > traffic engineering connections in accordance with our agreements > together)) via a mechanism of their choice. This calculation will create > a database that they will then load into an appropriate cache within > their POP routers. This cache will contain the calculations for > ***entire Internet DNS table*** because they must not presume that all > of our traffic will always remain limited to the few hundred remote ASes > that we primarily deal with. I further presume that only deltas > (changes) will need to be loaded and that the cache updates will not > require the routers to go off-line at any point. > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 09: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 1HXHL1-0006DC-9t; Fri, 30 Mar 2007 09:40:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXHL0-0006D4-2t for ram@iab.org; Fri, 30 Mar 2007 09:40:18 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXHKy-0007Ny-Lj for ram@iab.org; Fri, 30 Mar 2007 09:40:18 -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 6428979; Fri, 30 Mar 2007 08:40:04 -0500 In-Reply-To: <460CE997.9010902@zurich.ibm.com> References: <45F94921.7010707@piuha.net> <45FC10FD.2060507@piuha.net> <0A72F546-9BB9-4F1C-9478-36CD785FE197@muada.com> <8C9386510C30DCC-1780-504F@FWM-M10.sysops.aol.com> <43298230-F92B-426C-8735-84FA78202CF6@muada.com> <7CF3DDEA-74DF-4117-BD00-7BDF48A21E6D@cisco.com> <460CE997.9010902@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1165796F-B845-4138-958D-5AD30D9A0246@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [RAM] what we should be working on Date: Fri, 30 Mar 2007 09:40:00 -0400 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 Hello; On Mar 30, 2007, at 6:42 AM, Brian E Carpenter wrote: > (in catch up mode) > > On 2007-03-20 08:31, Tony Li wrote: >> On Mar 20, 2007, at 8:26 AM, Iljitsch van Beijnum wrote: >>> On 20-mrt-2007, at 6:52, Tony Li wrote: >>> >>>> Raising the average packet size would increase jitter. This may >>>> well be irrelevant at GigE speeds, but at lower speeds could >>>> become significant. Someone should work the figures... >>> >>> How much jitter is acceptable? >> This is also all over the map and is really the domain of our VOIP >> and video brethren. I'll let them speak for themselves. > > I'm not one of them, but I believe the answer is that on links I am one of them (video, not VOIP) > where this is an issue you will run a couple of diffserv classes, Yes, > and in the class used for real time traffic the packet sizes will > be uniform and an EF queuing discipline will manage jitter. I would Uniform packet sizes ? Not in modern-day video, at least, not if you have any control traffic or any audio traffic or a MPEG GOP type encoding or are using variable bit rate (all of which are used in most practice). For example, looking at one of my H.264 1 Mbps streams, fairly few of the packets are near the MTU (set at 1450 bytes). For broadcasts, buffers are huge (seconds), so the issue is with video conferencing and other real time video. There, there are typically two causes of issues - the dynamics of human interactions mean that you like to keep latency down below a few 100 milliseconds, end to end. This means that jitter needs to be kept to less than, say, 100 msec at most. - The arrival of certain packets may be taken as signals, for example, the first packet of a new video frame may signal the decoder to flush the old video frame. (This may even be required, depending on memory available, etc.) - Generally, there is a timer, and if a packet is expected but not received by a certain time, it is assumed lost. Jitter that causes certain packets to be out of order or too late can thus cause effective packet loss in videoconferencing. This is more likely than it causing human factor problems directly. The direction of all Internet video is strongly towards increasing the bit rate and the frame rate, which makes raising the MTU at least a little attractive. Suppose you are sending 10 Mbps HD 60 fps for telepresence. (I will ignore overheads to keep the math simple.) This would be (at least) 834 pps for a 1500 byte MTU, and 140 pps for a 9000 byte MTU. For a 1 Mbps 30 fps SD stream, there would be (again, at a minimum) 84 pps at 1500 bytes and 14 pps for 9000 bytes. The latter is worrisome, as 14 pps < 30 fps, but the encoder packetizer would almost certainly respond by simply not making use of it (i.e., in the 1 Mbps 30 fps case, the actual MTU used would effectively be no more than ~ 4200 bytes, and the average packet size would thus be even less). You would occasionally see a longer packet (say, at the beginning of a new GOP), but they would be rare. So in practice I think that what this means is that increasing the MTU limit will quickly reach a point of diminishing return, at least for real time systems with current video systems. Going from 9000 bytes to 90,000 bytes would be pretty irrelevant for videoconferencing, for example. If we ever started doing a lot of uncompressed HD at multiple Gbps, then these considerations would of course change. > be shocked if we needed to do this on underloaded GigE access links > or on provider backbones. There, an MTU that readily accommodates > encapsulation overhead seems appropriate. > My advise is to set the MTU to be efficient, and let the codecs worry about their packet sizes. > Brian Regards Marshall >>> >>> It would also be helpful to know the amount of buffering that >>> happens in routers and switches, but that seems to be all over >>> the map. >> Correct. It very much depends on make and model. There is no >> hard and fast standard. >> 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 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 10:07: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 1HXHjv-0002Yw-Qf; Fri, 30 Mar 2007 10:06:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXHju-0002Ym-QG for ram@iab.org; Fri, 30 Mar 2007 10:06:02 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXHjs-0006Vp-F2 for ram@iab.org; Fri, 30 Mar 2007 10:06:02 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 30 Mar 2007 07:05:58 -0700 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 l2UE5vZT013051; Fri, 30 Mar 2007 07:05:57 -0700 Received: from [10.71.15.118] (sjc-vpn1-1260.cisco.com [10.21.100.236]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2UE5rMF004281; Fri, 30 Mar 2007 14:05:57 GMT Message-ID: <460D1941.6030604@cisco.com> Date: Fri, 30 Mar 2007 10:05:53 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: "Fleischman, Eric" Subject: Re: [RAM] Incremental Deployment of LISP References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu><0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com><474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com><05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774857@XCH-NW-7V2.nw.nos.boeing.com> <761E822F-5D0D-47C8-B59C-451DFC7B6AF4@cisco.com> <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1095; t=1175263557; x=1176127557; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=m+lf3Fi6hdno/RPvhugmiW04uGxMXuN2TbVm2PN6Uwc=; b=Rl04y//mlPLniHYGwpomylmPhPVkA9FItaj9OYpjtxWWv/XalleG99WyznOmZI3EuwzmxCy5 ea3Ls1mVSdBGDLX5+Ut8UVUGlUaInEz1j7fSpfp3brQwGkWuTqUFY7/h; Authentication-Results: sj-dkim-4; header.From=riw@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 > Speaking as a (very) large end user representing what I (perhaps > incorrectly) expect the ISPs supporting us to do, I believe that this is > not a problem for the following reason: It might not be a problem for a very large enterprise along the edge. But: 1. What about MANET? 2. What about wireless laptops roaming around, even in venues like the IETF? 3. What about experimental concept testing? 4. What about little users, like SOHO and individual users in their homes? I suppose you could say: "Well, there will always be a service provider, so this isn't a problem." While the service providers on list would love to hear that (it's akin to the little bells on the cash register ringing), I don't think it's the best thing for the Internet or IP networks in general. :-) Russ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGDRlBER27sUhU9OQRAsPGAJ9KeobvWLUjr0klRPfie9RQY51KCACg3wiJ 9gixOnImk8AiRbevNxLZ/2o= =uUpa -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 10:59: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 1HXIXG-0003MT-Ir; Fri, 30 Mar 2007 10:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXIXF-0003MO-OZ for ram@iab.org; Fri, 30 Mar 2007 10:57:01 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXIXE-0002f8-FD for ram@iab.org; Fri, 30 Mar 2007 10:57:01 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Mar 2007 16:57:00 +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 l2UEuxi3022079; Fri, 30 Mar 2007 16:56:59 +0200 Received: from [212.254.247.6] (ams3-vpn-dhcp4223.cisco.com [10.61.80.126]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2UEuxlZ009066; Fri, 30 Mar 2007 14:56:59 GMT Message-ID: <460D253A.100@cisco.com> Date: Fri, 30 Mar 2007 16:56:58 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> In-Reply-To: <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.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=1359; t=1175266619; x=1176130619; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=ejtVJjWwoK8nfTOX677PI+pkQlh1+YzrkWWsqMvBfDc=; b=JmbnuK8rZcF3wVIf0N01Psuvw7tT51ejeCDgR33v7zWoHZkKsXuUH0eo5vdIqqEo8yRgQ2wL PerTLhxU8sGNMza4wD0fMH3kwSm38PG49T2ERrYP2f6UiGRhCcyzVW7J; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Roland Dobbins wrote: > > On Mar 29, 2007, at 12:28 PM, Noel Chiappa wrote: > >> It's a general law of system design that as systems grow, it's >> usually the >> case that a single mechanism A that did both X and Y needs to get >> separated >> into two separate mechanisms B and C, one each for X and Y - which >> means that >> it would be an extremely bad idea to go in the reverse direction as a >> system >> got larger. >> >> In other words, trying to do both: >> - finding out where some user/computer/etc is, and >> - finding out if/how to get there >> in a single mechanism would be a really bad idea. > > The DNS won't work, and deploying some other infrastructure (X.500? > Something Else?) to handle lookups is a nonstarter, IMHO. Lookups are a non-starter because of the lookup latency and what you do with a packet on a cache miss (it's important to say why they're a non-starter, Roland ;-). We want something that is akin to the RADB (perhaps a big table that can be diffed periodically), but to be sure is administered easily by end systems. This goes to my earlier question of whether size matters. Can a router keep this table in fast memory? OTOH, there's an argument to be made that with only PA addresses in the routing table you can "borrow" space from today's PI entries. Eliot Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 11:37: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 1HXJ9R-0003MJ-Hh; Fri, 30 Mar 2007 11:36:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJ9Q-0003ME-FS for ram@iab.org; Fri, 30 Mar 2007 11:36:28 -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 1HXJ9P-0001ID-4K for ram@iab.org; Fri, 30 Mar 2007 11:36:28 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2UFaPW2022998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Mar 2007 08:36:26 -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 l2UFaPAF003908; Fri, 30 Mar 2007 10:36:25 -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 l2UFaGO1003628; Fri, 30 Mar 2007 10:36:24 -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); Fri, 30 Mar 2007 08:36: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 Subject: RE: [RAM] The DNS? Which DNS? (Was: Incremental Deployment of LISP Date: Fri, 30 Mar 2007 08:36:21 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177485F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20070330132029.GA23969@nic.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] The DNS? Which DNS? (Was: Incremental Deployment of LISP Thread-Index: AcdyznCie7CFlpeGR0utEaPLUASUgQAEiN6w References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu><0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com><474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com><05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com><44231989-E7CA-41B9-BF11-371FD0B4C618@virtualized.org> <20070330132029.GA23969@nic.fr> From: "Templin, Fred L" To: "Stephane Bortzmeyer" , X-OriginalArrivalTime: 30 Mar 2007 15:36:22.0115 (UTC) FILETIME=[2B306B30:01C772E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 I think the subject of this message hits the mark, and maybe there is some confusion about what needs to go in the global DNS. Only FQDNs with locators for egress tunnel routers need to go in the global DNS, and that is not a lot more than what we are asking the global DNS to carry today. FQDNs for the services themselves are not resolved in the global DNS; they are resolved in site-specific name services instead. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr]=20 > Sent: Friday, March 30, 2007 6:20 AM > To: ram@iab.org > Subject: [RAM] The DNS? Which DNS? (Was: Incremental=20 > Deployment of LISP >=20 > On Fri, Mar 30, 2007 at 11:26:56AM +0100, > David Conrad wrote=20 > a message of 28 lines which said: >=20 > > >And the DNS contains a mess of unpatched, insecure hosts which > > >nobody maintains - this is true of routers and other network > > >infrastructure too, to some extent, but less than the DNS, IMHO, > > >and, unlike DNS servers, these devices will -have- to be upgraded > > >to work with the new system. > >=20 > > Please make a distinction between the DNS as a protocol and the DNS > > as it has been implemented. >=20 > And also please make a distinction between the protocol, the > implementation, and the social infrastructure which, today, operates > it. >=20 > Roland Dobbins said: >=20 > > But the entire workable solution has to be within the realm of the > > network infrastructure, there can't be any dependencies upon > > sysadmin groups, etc., because of the silos (both natural and > > unnatural) in which the relevant skillsets and responsibilities and > > interests of these groups seem to pretty much universally reside. >=20 > You can still use the DNS, the protocol and may be even the DNS, the > software, without relying on the social infrastructure (ICANN, the > registries, the name server operators).=20 >=20 > For instance, we could ask the IANA for a new DNS class (currently, IN > is the only one in wide use, CH being the closest second), set up a > new root which will depend only on the operator community (may be > through the RIRs) and then happily use the DNS protocol and the DNS > implementations, in a "restricted" environment (much more controlled > than the DNS as it is today). >=20 > This would avoid reinventing a mapping protocol which, as David Conrad > said, would probably be very close from the DNS.=20 >=20 >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 11:41: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 1HXJE3-00061e-KL; Fri, 30 Mar 2007 11:41:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJE3-00061Z-4E for ram@iab.org; Fri, 30 Mar 2007 11:41:15 -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 1HXJE1-00022L-Rn for ram@iab.org; Fri, 30 Mar 2007 11:41:15 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2UFfCUR026111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Mar 2007 08:41:12 -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 l2UFfCBw013427; Fri, 30 Mar 2007 10:41:12 -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 l2UFfBZH013394; Fri, 30 Mar 2007 10:41:11 -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); Fri, 30 Mar 2007 08:41:10 -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] Incremental Deployment of LISP Date: Fri, 30 Mar 2007 08:41:09 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <460D253A.100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: Acdy3Do7sR2i11wJQFGAwv3I0TNnjQABS6iA References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> From: "Templin, Fred L" To: "Eliot Lear" , "Roland Dobbins" X-OriginalArrivalTime: 30 Mar 2007 15:41:10.0868 (UTC) FILETIME=[D74CA140:01C772E1] 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 Eliot,=20 > > The DNS won't work, and deploying some other infrastructure=20 > (X.500? =20 > > Something Else?) to handle lookups is a nonstarter, IMHO. >=20 > Lookups are a non-starter because of the lookup latency and=20 > what you do with a packet on a cache miss (it's important to > say why they're a non-starter, Roland ;-). You seem to be assuming that the mapping will be driven by the first packet out the door; I'm not assuming that at all. For inter-site communications, there will always be an initial FQDN-to-locator resolution before a session starts, and the mapping can be done then before any packets are sent. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 12:18:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJkv-0003zf-L6; Fri, 30 Mar 2007 12:15:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXJkt-0003yE-Ty for ram@iab.org; Fri, 30 Mar 2007 12:15:11 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXJhv-0006tj-Ls for ram@iab.org; Fri, 30 Mar 2007 12:12:09 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l2UGC6Rh029791; Fri, 30 Mar 2007 08:12:06 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l2UGC2SE029789; Fri, 30 Mar 2007 08:12:02 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 30 Mar 2007 08:12:02 -0800 From: David Meyer To: "Templin, Fred L" Subject: Re: [RAM] The DNS? Which DNS? (Was: Incremental Deployment of LISP Message-ID: <20070330161202.GA29763@1-4-5.net> References: <20070330132029.GA23969@nic.fr> <39C363776A4E8C4A94691D2BD9D1C9A10177485F@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10177485F@XCH-NW-7V2.nw.nos.boeing.com> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "No wasted time, we're alive today, Churnin up the past, there's no easier way, Time's been between us, a means to an end, G_d it's good to be here walking together my friend" -- srv, Life By The Drop 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: , Content-Type: multipart/mixed; boundary="===============1462864253==" Errors-To: ram-bounces@iab.org --===============1462864253== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 30, 2007 at 08:36:21AM -0700, Templin, Fred L wrote: > I think the subject of this message hits the mark, and > maybe there is some confusion about what needs to go > in the global DNS. Only FQDNs with locators for egress > tunnel routers need to go in the global DNS, and that > is not a lot more than what we are asking the global > DNS to carry today. >=20 > FQDNs for the services themselves are not resolved in > the global DNS; they are resolved in site-specific name > services instead. I've said this once already, however, it might be instructive to look at the other existing instance where this has been tried, i.e., carrier/infrastructure ENUM. There are some lessons, both technical and non-technical to be learned there. See e.g. http://voipandenum.blogspot.com/2006/03/dallas-treaty-on-infrastructure-en= um.html --dmm --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFGDTbSORgD1qCZ2KcRAnSMAJ44EpMbjIjuKt6qI+3KQafzoU6UagCgj0/e GX2KaR5yLqTTIomnKKBFs7I= =vYdX -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- --===============1462864253== 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 --===============1462864253==-- From ram-bounces@iab.org Fri Mar 30 12:47:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKFD-0006Zo-O5; Fri, 30 Mar 2007 12:46:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKFC-0006Zd-3q for ram@iab.org; Fri, 30 Mar 2007 12:46:30 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXKF9-0004Je-GH for ram@iab.org; Fri, 30 Mar 2007 12:46:30 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 30 Mar 2007 09:46:27 -0700 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 l2UGkQqu005093; Fri, 30 Mar 2007 09:46:26 -0700 Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2UGkQA8022074; Fri, 30 Mar 2007 16:46:26 GMT In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <60B7DC87-CA3C-40B1-913E-933D04976E5F@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [RAM] Incremental Deployment of LISP Date: Fri, 30 Mar 2007 12:46:19 -0400 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=907; t=1175273186; x=1176137186; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=WT2okGU4yHEABNlB0Xp/Ipg2Sff/9/0LfkSc90YOB3g=; b=nJV9bmTNaf+hvVnu+Cz5p2aUcdJGvLqiIWbiiXM60EL/g5eSofLIRbkXtGvkG0unssRGbjzs 901/ZZQP4sRjoR+g8OBD6xodXnaJLdQAW6Qbvl8xTXBedoQqdsqFK2p3; Authentication-Results: sj-dkim-7; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Mar 30, 2007, at 11:41 AM, Templin, Fred L wrote: > Eliot, > >>> The DNS won't work, and deploying some other infrastructure >> (X.500? >>> Something Else?) to handle lookups is a nonstarter, IMHO. >> >> Lookups are a non-starter because of the lookup latency and >> what you do with a packet on a cache miss (it's important to >> say why they're a non-starter, Roland ;-). > > You seem to be assuming that the mapping will be driven by > the first packet out the door; I'm not assuming that at all. > For inter-site communications, there will always be an initial > FQDN-to-locator resolution before a session starts, What triggers this? > and the > mapping can be done then before any packets are sent. > > Fred > fred.l.templin@boeing.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 Fri Mar 30 12:50: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 1HXKIM-00087U-HA; Fri, 30 Mar 2007 12:49:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKIL-00087O-9J for ram@iab.org; Fri, 30 Mar 2007 12:49:45 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXKII-0004pK-WF for ram@iab.org; Fri, 30 Mar 2007 12:49:45 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 30 Mar 2007 09:49:43 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2UGngZE018971 for ; Fri, 30 Mar 2007 09:49:42 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2UGngA8023494 for ; Fri, 30 Mar 2007 16:49:42 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070330132029.GA23969@nic.fr> References: <20070329195425.A5F4C87324@mercury.lcs.mit.edu> <0DE0B7FC-9EC1-43B4-9AC7-A19EAF8DDCD9@cisco.com> <474EEBD229DF754FB83D256004D0210802584E9F@XCH-NW-6V1.nw.nos.boeing.com> <05800907-FC55-4F2A-8DF5-0C3FA5E5209E@cisco.com> <44231989-E7CA-41B9-BF11-371FD0B4C618@virtualized.org> <20070330132029.GA23969@nic.fr> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] The DNS? Which DNS? (Was: Incremental Deployment of LISP Date: Fri, 30 Mar 2007 09:49:57 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=740; t=1175273382; x=1176137382; c=relaxed/simple; s=sjdkim8002; 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]=20The=20DNS?=20Which=20DNS?=20(Was=3A=20Increme ntal=20Deployment=20of=20LISP |Sender:=20; bh=cbZfv4EzgzfeFJGukxhTSpKVEQ93PPTm5OE1WqEjYA8=; b=k9F9Qggl8Jv43Ng9CjjV5mzb4lK/6CJ/GdVp+dsZsAxkpfdrxxUlmFAgwKebg3LZ20gHk/yJ 326z0fgPgYsOH8C1Bvw0++mCYZFbw3wxlxxEJxacHTwUHJ5vWJ4YZ2J+; Authentication-Results: sj-dkim-8; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Mar 30, 2007, at 6:20 AM, Stephane Bortzmeyer wrote: > You can still use the DNS, the protocol and may be even the DNS, the > software, without relying on the social infrastructure (ICANN, the > registries, the name server operators). When I say 'the DNS', I mean the system, not the protocol, as well as the social infrastructure. The protocol isn't at issue, agree completely. That's been the convention for many years, by the bye - 'DNS' = protocol, 'the DNS' = system. ;> ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 12:50: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 1HXKJ3-0000Md-08; Fri, 30 Mar 2007 12:50:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKJ2-0000Jn-7w for ram@iab.org; Fri, 30 Mar 2007 12:50:28 -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 1HXKIz-0004wC-Uq for ram@iab.org; Fri, 30 Mar 2007 12:50:28 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2UGoOqO012362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Mar 2007 09:50:25 -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 l2UGoOIZ005384; Fri, 30 Mar 2007 11:50:24 -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 l2UGoGlw005120; Fri, 30 Mar 2007 11:50:24 -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); Fri, 30 Mar 2007 09:50:23 -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] Incremental Deployment of LISP Date: Fri, 30 Mar 2007 09:50:22 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774864@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <60B7DC87-CA3C-40B1-913E-933D04976E5F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: Acdy6vXzrkLKK+/bQ3+y8+AzYmbangAABgNQ References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <60B7DC87-CA3C-40B1-913E-933D04976E5F@cisco.com> From: "Templin, Fred L" To: "David R Oran" X-OriginalArrivalTime: 30 Mar 2007 16:50:23.0968 (UTC) FILETIME=[82BD6600:01C772EB] 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 > > You seem to be assuming that the mapping will be driven by > > the first packet out the door; I'm not assuming that at all. > > For inter-site communications, there will always be an initial > > FQDN-to-locator resolution before a session starts, > What triggers this? Client resolves a FQDN for a service, and ITR 1) resolves a FQDN for the ETR, then 2) resolves the FQDN for the service, then 3) returns the results of the latter to the client. Yes - this means that I expect the client's DNS server to be co-located with the ITR. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 12:56:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKOR-0007XW-HH; Fri, 30 Mar 2007 12:56:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKOP-0007Wz-L0 for ram@iab.org; Fri, 30 Mar 2007 12:56:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXKOO-0006Bl-8V for ram@iab.org; Fri, 30 Mar 2007 12:56:01 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 30 Mar 2007 09:56:00 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l2UGtx7l020874; Fri, 30 Mar 2007 09:55:59 -0700 Received: from [10.32.245.152] (stealth-10-32-245-152.cisco.com [10.32.245.152]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2UGtwA8025692; Fri, 30 Mar 2007 16:55:59 GMT In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774864@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <60B7DC87-CA3C-40B1-913E-933D04976E5F@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774864@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C487B68-847D-4307-9328-FBDAE9DD045B@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [RAM] Incremental Deployment of LISP Date: Fri, 30 Mar 2007 12:55:52 -0400 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1071; t=1175273759; x=1176137759; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=uBHhF0uKZwt/QQitm7E/3VbTkPuiO2kNqZ4oMgtlMXQ=; b=p+ZY7yVDWmnoPHTrjsYGyVQZjGN/aIvasiAr2MU8OUpz+vatCt0cKoZtpH5A7ktH7/0ZvbHT Hg836BzPGarLjy4yFatv9lEeR1d0Iy6vAIhIgPzab69l/vq6RXrD/TTo; Authentication-Results: sj-dkim-8; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) 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 Mar 30, 2007, at 12:50 PM, Templin, Fred L wrote: >>> You seem to be assuming that the mapping will be driven by >>> the first packet out the door; I'm not assuming that at all. >>> For inter-site communications, there will always be an initial >>> FQDN-to-locator resolution before a session starts, >> What triggers this? > > Client resolves a FQDN for a service, and ITR 1) resolves a > FQDN for the ETR, then 2) resolves the FQDN for the service, > then 3) returns the results of the latter to the client. > Ah, so you propose host changes? That's what I didn't understand. That certaily falls into one category of approaches (HIP, Shim6, etc.) but has nothing to do with LISP. Sorry if I thought from the subject line we were still tlakng about LISP, or similar approaches that only touch routers. What I still don't see is what triggers step (1). Are you proposing DNS snooping? Seems like it... > Yes - this means that I expect the client's DNS server to > be co-located with the ITR. > > Fred > fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 13:04: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 1HXKV4-0002oS-Ng; Fri, 30 Mar 2007 13:02:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKV3-0002oM-Gf for ram@iab.org; Fri, 30 Mar 2007 13:02:53 -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 1HXKV2-0007NN-7z for ram@iab.org; Fri, 30 Mar 2007 13:02:53 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2UH2pIh027592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Mar 2007 10:02:51 -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 l2UH2pWL002542; Fri, 30 Mar 2007 10:02:51 -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 l2UH2kfV002370; Fri, 30 Mar 2007 10:02:50 -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, 30 Mar 2007 10:02: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 Subject: RE: [RAM] Incremental Deployment of LISP Date: Fri, 30 Mar 2007 10:02:44 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774866@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <0C487B68-847D-4307-9328-FBDAE9DD045B@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: Acdy7EyDZswiOLHFTOyGUfwLRVgQxQAAA9Xg References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <60B7DC87-CA3C-40B1-913E-933D04976E5F@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774864@XCH-NW-7V2.nw.nos.boeing.com> <0C487B68-847D-4307-9328-FBDAE9DD045B@cisco.com> From: "Templin, Fred L" To: "David R Oran" X-OriginalArrivalTime: 30 Mar 2007 17:02:45.0634 (UTC) FILETIME=[3CCEA620:01C772ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 > > Client resolves a FQDN for a service, and ITR 1) resolves a > > FQDN for the ETR, then 2) resolves the FQDN for the service, > > then 3) returns the results of the latter to the client. > > > Ah, so you propose host changes? That's what I didn't understand. > That certaily falls into one category of approaches (HIP, Shim6, =20 > etc.) but has nothing to do with LISP. Sorry if I thought from the =20 > subject line we were still tlakng about LISP, or similar approaches =20 > that only touch routers. No, I'm not assuming host changes at all; I am only assuming changes for routers (ITRs and ETRs) the same as for LISP. =20 > What I still don't see is what triggers step (1). Are you proposing =20 > DNS snooping? Seems like it... I am talking here about a "two-faced" DNS server - one that acts as an ordinary DNS server inside the site and acts as a DNS client outside of the site. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 13:21: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 1HXKkn-0004jH-KE; Fri, 30 Mar 2007 13:19:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKkm-0004jB-UA for ram@iab.org; Fri, 30 Mar 2007 13:19:08 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXKkl-0001xy-LJ for ram@iab.org; Fri, 30 Mar 2007 13:19:08 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Mar 2007 19:19:08 +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 l2UHJ61g009998; Fri, 30 Mar 2007 19:19:06 +0200 Received: from [212.254.247.6] (ams3-vpn-dhcp4593.cisco.com [10.61.81.240]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2UHJ6lZ014624; Fri, 30 Mar 2007 17:19:06 GMT Message-ID: <460D468A.3030300@cisco.com> Date: Fri, 30 Mar 2007 19:19:06 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774860@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=642; t=1175275147; x=1176139147; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=flJKzqokzr0ZFRsPH9eEwYcnj2jfpzi6vWSluo4f97A=; b=ZCUIeLVFi2E9qFy+aQJOtGOCFMsQrCVPmfdeCtn6e7h48k12N/DR5hfjuSyniD+46LdbwPRC JPlF01azMk3fvdNtLlMoCEgEfLzGkvTobjg4G7kdsBo9cKA73NB+U+Gk; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 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 Hi Fred, > You seem to be assuming that the mapping will be driven by > the first packet out the door; I'm not assuming that at all. > For inter-site communications, there will always be an initial > FQDN-to-locator resolution before a session starts, and the > mapping can be done then before any packets are sent. > Sorry, Yes. I had my head in LISP, where really there is no end host interaction. I think that's a good thing, in as much as it becomes deployable faster due to a smaller set of processors being touched. But in a context, say, like HIP, you would want to do that exact resolution for a HIT. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 13:26:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKrr-0001uE-JD; Fri, 30 Mar 2007 13:26:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXKrq-0001u7-S8 for ram@iab.org; Fri, 30 Mar 2007 13:26:26 -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 1HXKrp-0002md-LH for ram@iab.org; Fri, 30 Mar 2007 13:26:26 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2UHQOsG007195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Mar 2007 12:26:24 -0500 (CDT) 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 l2UHQOmo020379; Fri, 30 Mar 2007 12:26:24 -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 l2UHQIrq020114; Fri, 30 Mar 2007 12:26:24 -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); Fri, 30 Mar 2007 10:26:23 -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] Incremental Deployment of LISP Date: Fri, 30 Mar 2007 10:26:22 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774867@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <460D468A.3030300@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: Acdy74fnw/f5zAYPT8m8LpOvuH4MaQAABo3Q References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <460D468A.3030300@cisco.com> From: "Templin, Fred L" To: "Eliot Lear" X-OriginalArrivalTime: 30 Mar 2007 17:26:23.0137 (UTC) FILETIME=[89B47110:01C772F0] X-Spam-Score: 0.0 (/) 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 > Sorry, Yes. I had my head in LISP, where really there is no end host=20 > interaction. I think that's a good thing, in as much as it becomes=20 > deployable faster due to a smaller set of processors being touched. But > in a context, say, like HIP, you would want to do that exact resolution > for a HIT. I guess what I have in mind could be considered something of a middle ground between LISP and HIP (although the terminology would be closer to that of LISP). Things in the real world are rarely either one way or the other; they are usually "shades of gray" between black-and-white. Thanks - Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 13:51: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 1HXLEx-00005Q-FV; Fri, 30 Mar 2007 13:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXLEw-00005K-Gy for ram@iab.org; Fri, 30 Mar 2007 13:50:18 -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 1HXLEs-0006J0-SE for ram@iab.org; Fri, 30 Mar 2007 13:50:18 -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 l2UHo0rQ022515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Mar 2007 12:50:01 -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 l2UHo0vk011855; Fri, 30 Mar 2007 10:50:00 -0700 (PDT) Received: from XCH-NWBH-10.nw.nos.boeing.com (xch-nwbh-10.nw.nos.boeing.com [130.247.55.83]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l2UHo0h1011838; Fri, 30 Mar 2007 10:50:00 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 10:49:59 -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] Incremental Deployment of LISP Date: Fri, 30 Mar 2007 10:49:58 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <22000.61535.qm@web58714.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: Acdyz9Sk6mTC1R0BRGu20zPu6PUdPgAE7a8g References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com> From: "Fleischman, Eric" To: , , X-OriginalArrivalTime: 30 Mar 2007 17:49:59.0356 (UTC) FILETIME=[D5D64FC0:01C772F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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 No, I'm not talking about a private network, I am rather attempting to talk about the algorithmic change that is embedded within LISP. Last night it occurred to me that this particular posting of mine presumed too many concepts and that I owe a more complete explanation to this list. Before doing so, I'd like to state that I am excited about the LISP concept itself, but not "sold" on any specific LISP alternative. The reason I am defending the DNS alternative is because I believe that the analysis that have been posted to this list concerning the DNS alternative have not considered the implications of the powerful algorithmic change latent within the LISP concept itself. I believe that LISP offers the Internet a very valuable abstraction that occurs at the ISP itself, which simultaneously offers both the ISP and its customers considerable business advantages over the current system while also addressing the Internet scaling problem, particularly the BGP scaling issues. For example, perhaps many equate the tunnel endpoints to the PE-CE boundaries defined by L3VPN. This may indeed be the case, but I believe that it is a local ISP engineering decision concerning where those tunnel end points actually occur. The tunnels can be highly aggregated. Alternatively, they can be highly customer specific. Some may equate the size of the DNS table with the current Internet BGP table. This may or may not be the case depending on how aggegatable the LISP implementation turns out to be (e.g., tunnel end point placement within the ISPs). Regardless, I believe that a local summary of that DNS table from the point-of-view of each specific ISP router servicing a tunnel endpoint will be simpler than the DNS tables themselves and will be smaller than today's Internet BGP tables. (It is that local route summary that I was describing in my previous posting below.) There are two reasons for this: 1) Larger ISPs will probably have economic incentives to locally route as many packets as possible within their own infrastructures. Specifically, they will probably retain their L3VPN and L2VPN product offerings. For example, the ISPs with whom we have negotiated MPLS service connectivity are likely to continue to offer us this service. More generally, in LISP the connections of any service that is localized to a single ISP -- or to a group of confederated ISPs (e.g., see RFC 1955) -- behave differently than today's BGP tables, and will result in local tunnel routing tables (from the point-of-view of that local ISP) that are substantially smaller than the Internet DNS table. Routes entirely supported locally by that ISP (or the confederation of ISPs to which it belongs) need not be tunneled by that ISP. However, this is not the case for remote ISPs which will need to access the Local-ISP-supported ASes through tunneling. But that fact need not effect the tunnel address calculations of the local ISP itself, simplifying those local calculations. 2) It is conceivable that ISPs may receive numerous requests to connect enterprises that internally use private addresses (e.g., Net10). That ISP will negotiate with those enterprises how this will be accomplished. They will also support many home users and many small businesses. The public addressing of these entities will use PA addresses from that ISP, which will be highly aggregated. That aggregation could be retained in the Internet DNS entries if the tunnel endpoints provided by that ISP similarly permit aggregation (i.e., are deeper within the ISP than at the PE-CE boundaries to the supported ASes). The LISP approach also empowers us end users. For example, my coworkers and I have been telling various IETF mail lists for the past decade that it is non-negotiable that we will solely accept PI addresses whether or not the IETF permits a PA-PI address distinction to exist or not. The world's other largest companies and governments are almost certainly going to make similar demands. It simply doesn't matter what the IETF thinks about this (and thus the IETF needs to just deal with it, which it recently appears to be doing) because it is unlikely that ISPs will lose the business of their largest customers over their internal addressing requirements (i.e., re-addressing is very expensive with no attendant business gain). Worse comes to worse, we will just decree that we are also ISPs because of our huge sizes. LISP resolves this dispute by making internal addressing irrelevant to anybody but the corporation (or government or whatever) itself and the ISPs that support it. LISP therefore promises that the shadow of IP addressing will diminish from business and Internet scaling, which is A Good Thing. Equally important, it also promises that the IETF will again have a coherent and common Internet architecture vision, which is a philosophical grounding that many of us have been longing for for quite some time. -----Original Message----- From: Peter Sherbin [mailto:pesherb@yahoo.com]=20 Sent: Friday, March 30, 2007 6:32 AM To: Fleischman, Eric; rdobbins@cisco.com; ram@iab.org Subject: RE: [RAM] Incremental Deployment of LISP Speaking as a (large) ISP I hear a client wanting a sort of a private network with a kind of a class of service at price of a shared best effort bandwidth. TANSTAFL :) Thanks, Peter --- "Fleischman, Eric" wrote: > From: Roland Dobbins [mailto:rdobbins@cisco.com] > >It would be in the sense that -routing of packets- would break=20 > >without > it, > >and a critical dependency for routing packets would for the first=20 > >time > in > >the history of the Internet be outside the control of network > operators, > >thrust upon people who don't understand and don't want the > responsibility > >in the first place. >=20 > Speaking as a (very) large end user representing what I (perhaps > incorrectly) expect the ISPs supporting us to do, I believe that this=20 > is not a problem for the following reason: >=20 > We negotiate our Internet service with our ISPs. This is an involved=20 > process that is not done overnight, to say the least. Each ISP=20 > provides ingress and egress paths to the Internet for us. The=20 > disproportionate percentage of our traffic goes to a finite number=20 > (let's say a few hundred -- but this number is not relevant) of remote > ASes via a small set of ISP-provided routers that are connected to a=20 > small-set of POP routers that we provide. These ISP-provided routers=20 > will not be looking up DNS entries at any point because the latency=20 > involved with DNS lookups could not support the very high data rates=20 > that they have committed to support in their business agreements with=20 > us. For this reason, I expect that the ISPs will periodically map the=20 > Remote AS-to Remote-Internet-tunnel-endpoint relationships contained=20 > in the then current DNS tables (from the perspective of their position > within the Internet (e.g., in regards to load-balancing and=20 > multi-homing and traffic engineering connections in accordance with=20 > our agreements > together)) via a mechanism of their choice. This calculation will=20 > create a database that they will then load into an appropriate cache=20 > within their POP routers. This cache will contain the calculations for > ***entire Internet DNS table*** because they must not presume that all > of our traffic will always remain limited to the few hundred remote=20 > ASes that we primarily deal with. I further presume that only deltas > (changes) will need to be loaded and that the cache updates will not=20 > require the routers to go off-line at any point. >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 =20 ________________________________________________________________________ ____________ Looking for earth-friendly autos?=20 Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 14:04:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXLS4-00016F-E3; Fri, 30 Mar 2007 14:03:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXLS3-00014W-RE for ram@iab.org; Fri, 30 Mar 2007 14:03:51 -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 1HXLS2-0000bW-HP for ram@iab.org; Fri, 30 Mar 2007 14:03:51 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2UI3mAG007651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Mar 2007 11:03:48 -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 l2UI3mjS011214; Fri, 30 Mar 2007 11:03:48 -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 l2UI3ltV011194; Fri, 30 Mar 2007 11:03:47 -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, 30 Mar 2007 11:03:35 -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] Incremental Deployment of LISP Date: Fri, 30 Mar 2007 11:03:34 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177486A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774866@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: Acdy7EyDZswiOLHFTOyGUfwLRVgQxQAAA9XgAAI7c1A= References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com><60B7DC87-CA3C-40B1-913E-933D04976E5F@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774864@XCH-NW-7V2.nw.nos.boeing.com><0C487B68-847D-4307-9328-FBDAE9DD045B@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774866@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Templin, Fred L" , "David R Oran" X-OriginalArrivalTime: 30 Mar 2007 18:03:35.0712 (UTC) FILETIME=[BC6C5A00:01C772F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 > No, I'm not assuming host changes at all; I am only assuming > changes for routers (ITRs and ETRs) the same as for LISP. Note that I am specifically not meaning to make any statement about what kind of platform should be considered as a "router". But, I do believe that the ITR should be located as close to the end host as possible. Fred fred.l.templin@boeing.com=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 14:08:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXLVt-0004Qm-Re; Fri, 30 Mar 2007 14:07:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXLVs-0004Qc-W3 for ram@iab.org; Fri, 30 Mar 2007 14:07:48 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXLVq-0001UI-NG for ram@iab.org; Fri, 30 Mar 2007 14:07:48 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 30 Mar 2007 11:07:45 -0700 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 l2UI7imh030437 for ; Fri, 30 Mar 2007 11:07:44 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2UI7iA8027833 for ; Fri, 30 Mar 2007 18:07:44 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com> <474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Fri, 30 Mar 2007 11:07:59 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=954; t=1175278064; x=1176142064; c=relaxed/simple; s=sjdkim5002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=Ik6Add30f2amfKyY7JOOXSq+lLldvf5PJoeBYkagXJE=; b=JmescimYYOXXmxcKPVpjicQ16f2NdUnK8yv3CNWFEmnXoxgR5rVaaBnQKBnBPtQCHWsAsOM2 h5dos0iI+cUMvhHBA8k1pnpfBo79vEeL7coAkobzl0izfvSY4NoxXlzi; Authentication-Results: sj-dkim-5; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Mar 30, 2007, at 10:49 AM, Fleischman, Eric wrote: > 2) It is conceivable that ISPs may receive numerous requests to > connect > enterprises that internally use private addresses (e.g., Net10). Perhaps I'm wrong, but it seems to me that this type of connectivity isn't generally handled by SPs, but is handled by the enterprises themselves. RFC1918 collision is certainly an issue in these scenarios, often resulting in bidirectional NATting and other ugliness. In your view, does LISP or another solution in this general space apply only to the Internet, and only to ISP-to-customer communications? Someone else earlier mentioned MANET, what about disintermediation in general? ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 14:13: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 1HXLbS-0007KL-4x; Fri, 30 Mar 2007 14:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXLbQ-0007KG-N2 for ram@iab.org; Fri, 30 Mar 2007 14:13:32 -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 1HXLbL-0002Mt-Ql for ram@iab.org; Fri, 30 Mar 2007 14:13:32 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2UIDQGK005520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Mar 2007 11:13:26 -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 l2UIDQrO002474; Fri, 30 Mar 2007 13:13:26 -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 l2UIDJOw002257; Fri, 30 Mar 2007 13:13:25 -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); Fri, 30 Mar 2007 11:13:21 -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] Incremental Deployment of LISP Date: Fri, 30 Mar 2007 11:13:20 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177486B@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: Acdy9ltIXICBtLHQReGil0CNTMed0gAACxyA References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> From: "Templin, Fred L" To: "Roland Dobbins" , X-OriginalArrivalTime: 30 Mar 2007 18:13:21.0860 (UTC) FILETIME=[19CB7040:01C772F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 > In your view, does LISP or another solution in this general space =20 > apply only to the Internet, and only to ISP-to-customer =20 > communications? Someone else earlier mentioned MANET, what about =20 > disintermediation in general? Just as an aside, if we want to talk about a solution that incorporates LISP-like concepts, DNS mapping, and MANET for intra-site navigations then we have to put IPvLX and its companion documents (including ISATAP) on the table; see: http://ipvlx.net (I can't give a timeframe, but this work is due to be updated.) Thanks - Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 14:54:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXMEI-00012n-Hq; Fri, 30 Mar 2007 14:53:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXMEH-00012i-Mp for ram@iab.org; Fri, 30 Mar 2007 14:53:41 -0400 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXMEE-00018B-2c for ram@iab.org; Fri, 30 Mar 2007 14:53:41 -0400 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id GAA15348; Sat, 31 Mar 2007 06:53:23 +1200 In-Reply-To: <460D468A.3030300@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <460D468A.3030300@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [RAM] Incremental Deployment of LISP Date: Sat, 31 Mar 2007 06:53:21 +1200 To: Eliot Lear X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "Templin, Fred L" , 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 31/03/2007, at 5:19 AM, Eliot Lear wrote: > Hi Fred, >> You seem to be assuming that the mapping will be driven by >> the first packet out the door; I'm not assuming that at all. >> For inter-site communications, there will always be an initial >> FQDN-to-locator resolution before a session starts, and the >> mapping can be done then before any packets are sent. >> > > Sorry, Yes. I had my head in LISP, where really there is no end > host interaction. I think that's a good thing, in as much as it > becomes deployable faster due to a smaller set of processors being > touched. But in a context, say, like HIP, you would want to do > that exact resolution for a HIT. > > Eliot And in fact, that's what the HIP documents say and the implementations try... of course, most of the time there's no answer at the moment. But it works when there is, and doesn't delay communication noticeably when there isn't. Andrew _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 14:54:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXMDG-0000eg-7s; Fri, 30 Mar 2007 14:52:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXMDE-0000e3-N3 for ram@iab.org; Fri, 30 Mar 2007 14:52:36 -0400 Received: from web58711.mail.re1.yahoo.com ([66.196.100.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HXMDD-0000ql-5O for ram@iab.org; Fri, 30 Mar 2007 14:52:36 -0400 Received: (qmail 24544 invoked by uid 60001); 30 Mar 2007 18:52:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=QKFrpAB0CCxleH0MD6sjHBWUjYS9nKYO8LEh/GwgYzYw83GetZhrDyByjd7+Lno0UUY4ur4sFtjsad0NMqpfHHEyUtoQQWd5+JQcPyNNd8lKEhEDqTmtJsVrq/KwhahwEXdUk75liwmZeHAW49t6iE4eI+opFokNZN9LhxPSt6c=; X-YMail-OSG: XcaitVoVM1mfORszfTNTKb0eOnjjvXGhxBcHMb8NHTCD0LJuIqpXe9yqRqgR44WrEg-- Received: from [207.107.50.100] by web58711.mail.re1.yahoo.com via HTTP; Fri, 30 Mar 2007 11:52:34 PDT Date: Fri, 30 Mar 2007 11:52:34 -0700 (PDT) From: Peter Sherbin Subject: RE: [RAM] Incremental Deployment of LISP To: "Fleischman, Eric" , rdobbins@cisco.com, ram@iab.org In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <952612.23138.qm@web58711.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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 Agreed with what you are saying, in particular on PI (ISP hat's off). > behave differently than today's BGP tables, and will result in > local tunnel routing tables IMO standards aim at making things just work e2e without a need for any intervention including local fine-tuning aka customization. LISP seems to prolong the original design, which might be OK for the short term. Thanks, Peter --- "Fleischman, Eric" wrote: > No, I'm not talking about a private network, I am rather attempting to > talk about the algorithmic change that is embedded within LISP. > > Last night it occurred to me that this particular posting of mine > presumed too many concepts and that I owe a more complete explanation to > this list. Before doing so, I'd like to state that I am excited about > the LISP concept itself, but not "sold" on any specific LISP > alternative. The reason I am defending the DNS alternative is because I > believe that the analysis that have been posted to this list concerning > the DNS alternative have not considered the implications of the powerful > algorithmic change latent within the LISP concept itself. > > I believe that LISP offers the Internet a very valuable abstraction that > occurs at the ISP itself, which simultaneously offers both the ISP and > its customers considerable business advantages over the current system > while also addressing the Internet scaling problem, particularly the BGP > scaling issues. > > For example, perhaps many equate the tunnel endpoints to the PE-CE > boundaries defined by L3VPN. This may indeed be the case, but I believe > that it is a local ISP engineering decision concerning where those > tunnel end points actually occur. The tunnels can be highly aggregated. > Alternatively, they can be highly customer specific. > > Some may equate the size of the DNS table with the current Internet BGP > table. This may or may not be the case depending on how aggegatable the > LISP implementation turns out to be (e.g., tunnel end point placement > within the ISPs). Regardless, I believe that a local summary of that DNS > table from the point-of-view of each specific ISP router servicing a > tunnel endpoint will be simpler than the DNS tables themselves and will > be smaller than today's Internet BGP tables. (It is that local route > summary that I was describing in my previous posting below.) > > There are two reasons for this: > 1) Larger ISPs will probably have economic incentives to locally route > as many packets as possible within their own infrastructures. > Specifically, they will probably retain their L3VPN and L2VPN product > offerings. For example, the ISPs with whom we have negotiated MPLS > service connectivity are likely to continue to offer us this service. > More generally, in LISP the connections of any service that is localized > to a single ISP -- or to a group of confederated ISPs (e.g., see RFC > 1955) -- behave differently than today's BGP tables, and will result in > local tunnel routing tables (from the point-of-view of that local ISP) > that are substantially smaller than the Internet DNS table. Routes > entirely supported locally by that ISP (or the confederation of ISPs to > which it belongs) need not be tunneled by that ISP. However, this is not > the case for remote ISPs which will need to access the > Local-ISP-supported ASes through tunneling. But that fact need not > effect the tunnel address calculations of the local ISP itself, > simplifying those local calculations. > > 2) It is conceivable that ISPs may receive numerous requests to connect > enterprises that internally use private addresses (e.g., Net10). That > ISP will negotiate with those enterprises how this will be accomplished. > They will also support many home users and many small businesses. The > public addressing of these entities will use PA addresses from that ISP, > which will be highly aggregated. That aggregation could be retained in > the Internet DNS entries if the tunnel endpoints provided by that ISP > similarly permit aggregation (i.e., are deeper within the ISP than at > the PE-CE boundaries to the supported ASes). > > The LISP approach also empowers us end users. For example, my coworkers > and I have been telling various IETF mail lists for the past decade that > it is non-negotiable that we will solely accept PI addresses whether or > not the IETF permits a PA-PI address distinction to exist or not. The > world's other largest companies and governments are almost certainly > going to make similar demands. It simply doesn't matter what the IETF > thinks about this (and thus the IETF needs to just deal with it, which > it recently appears to be doing) because it is unlikely that ISPs will > lose the business of their largest customers over their internal > addressing requirements (i.e., re-addressing is very expensive with no > attendant business gain). Worse comes to worse, we will just decree that > we are also ISPs because of our huge sizes. LISP resolves this dispute > by making internal addressing irrelevant to anybody but the corporation > (or government or whatever) itself and the ISPs that support it. > > LISP therefore promises that the shadow of IP addressing will diminish > from business and Internet scaling, which is A Good Thing. Equally > important, it also promises that the IETF will again have a coherent and > common Internet architecture vision, which is a philosophical grounding > that many of us have been longing for for quite some time. > > -----Original Message----- > From: Peter Sherbin [mailto:pesherb@yahoo.com] > Sent: Friday, March 30, 2007 6:32 AM > To: Fleischman, Eric; rdobbins@cisco.com; ram@iab.org > Subject: RE: [RAM] Incremental Deployment of LISP > > Speaking as a (large) ISP I hear a client wanting a sort of a private > network with a kind of a class of service at price of a shared best > effort bandwidth. TANSTAFL :) > > Thanks, > > Peter > --- "Fleischman, Eric" wrote: > > > From: Roland Dobbins [mailto:rdobbins@cisco.com] > > >It would be in the sense that -routing of packets- would break > > >without > > it, > > >and a critical dependency for routing packets would for the first > > >time > > in > > >the history of the Internet be outside the control of network > > operators, > > >thrust upon people who don't understand and don't want the > > responsibility > > >in the first place. > > > > Speaking as a (very) large end user representing what I (perhaps > > incorrectly) expect the ISPs supporting us to do, I believe that this > > is not a problem for the following reason: > > > > We negotiate our Internet service with our ISPs. This is an involved > > process that is not done overnight, to say the least. Each ISP > > provides ingress and egress paths to the Internet for us. The > > disproportionate percentage of our traffic goes to a finite number > > (let's say a few hundred -- but this number is not relevant) of remote > > > ASes via a small set of ISP-provided routers that are connected to a > > small-set of POP routers that we provide. These ISP-provided routers > > will not be looking up DNS entries at any point because the latency > > involved with DNS lookups could not support the very high data rates > > that they have committed to support in their business agreements with > > us. For this reason, I expect that the ISPs will periodically map the > > Remote AS-to Remote-Internet-tunnel-endpoint relationships contained > > in the then current DNS tables (from the perspective of their position > > > within the Internet (e.g., in regards to load-balancing and > > multi-homing and traffic engineering connections in accordance with > > our agreements > > together)) via a mechanism of their choice. This calculation will > > create a database that they will then load into an appropriate cache > > within their POP routers. This cache will contain the calculations for > > > ***entire Internet DNS table*** because they must not presume that all > > > of our traffic will always remain limited to the few hundred remote > > ASes that we primarily deal with. I further presume that only deltas > > (changes) will need to be loaded and that the cache updates will not > > require the routers to go off-line at any point. > > > > > > _______________________________________________ > > RAM mailing list > > RAM@iab.org > > https://www1.ietf.org/mailman/listinfo/ram > > > > > > > ________________________________________________________________________ > ____________ > Looking for earth-friendly autos? > Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. > http://autos.yahoo.com/green_center/ > ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 17:48: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 1HXOu5-0000Kj-8H; Fri, 30 Mar 2007 17:45:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXOu4-0000Kc-Ee for ram@iab.org; Fri, 30 Mar 2007 17:45:00 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXOu3-0001N9-5H for ram@iab.org; Fri, 30 Mar 2007 17:45:00 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 30 Mar 2007 14:44:59 -0700 X-IronPort-AV: i="4.14,355,1170662400"; d="scan'208"; a="699732832:sNHT34108338" Received: from rcallon-lt1.juniper.net ([172.23.1.243]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l2ULivJ26427; Fri, 30 Mar 2007 14:44:57 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 30 Mar 2007 16:47:08 -0400 To: Eliot Lear , "Templin, Fred L" , ram@iab.org From: Ross Callon Subject: Re: [RAM] Incremental Deployment of LISP In-Reply-To: <460D468A.3030300@cisco.com> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 At 07:19 PM 3/30/2007 +0200, Eliot Lear wrote: >Hi Fred, >>You seem to be assuming that the mapping will be driven by >>the first packet out the door; I'm not assuming that at all. >>For inter-site communications, there will always be an initial >>FQDN-to-locator resolution before a session starts, and the >>mapping can be done then before any packets are sent. > >Sorry, Yes. I had my head in LISP, where really there is no end host >interaction. I think that's a good thing, in as much as it becomes >deployable faster due to a smaller set of processors being touched. But >in a context, say, like HIP, you would want to do that exact resolution >for a HIT. > >Eliot This is beginning to hint at something that I have wondered about for a while: It seems to me that there could be cases where a router (perhaps in a private network, or a CE router, or perhaps even a PE router) receives some packets that already use a PA address, and some that are using a PI address and that need to be encapsulated. For example this might occur because deployment of LISP is not precisely equally rapid in each private network, or is not equally rapid in each site within a larger private network. How is a router supposed to know which packets are using an address that is available in the global BGP top-level routing table (such as a PA address), and which packets are using an address that needs to be mapped? For those routers that are in the default-free core of the Internet this might be easy: If you have a route, then use it. Else map. Of course these routers are probably large enough that the ratio between the speed of the data plane and the speed of the control plane is so large (perhaps in many cases a factor of 10,000 or greater) that you don't want them receiving any control packets specific to LISP, or at least any one control packet that they do receive better correspond to at least 10,000 data packets, on average. To me this implies that you want to push the mapping function outside of the default free core of the Internet. However, for many routers they will have a default route, and will not have the full global BGP routing table. I am thinking that the routers where you might want to do LISP will mostly (or perhaps entirely?) have a default route for most remote locations. Thus, if a packet has a destination address that matches the default route it *might* be a PA address and *might* be a PI address. Is the thought to partition the address space? The only other solution that I have thought of is to have strictly controlled topology (so that there is a clear boundary where the mapping is done). Thanks, Ross _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 20:51: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 1HXRll-00034U-Ut; Fri, 30 Mar 2007 20:48:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXRlk-00031m-GC for ram@iab.org; Fri, 30 Mar 2007 20:48:36 -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 1HXRlg-0004Z7-Or for ram@iab.org; Fri, 30 Mar 2007 20:48:36 -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.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l2V0mTBi009439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 30 Mar 2007 17:48:29 -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 l2V0mTbx005555 for ; Fri, 30 Mar 2007 17:48: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 l2V0mSHi005543 for ; Fri, 30 Mar 2007 17:48:29 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Mar 2007 17:48:28 -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: [RAM] Unlike IPv6, the underlying LISP business model is not inherently self-defeating Date: Fri, 30 Mar 2007 17:48:28 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Unlike IPv6, the underlying LISP business model is not inherently self-defeating Thread-Index: Acdyz9Sk6mTC1R0BRGu20zPu6PUdPgAE7a8gABAtLcA= References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com> <474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> From: "Fleischman, Eric" To: X-OriginalArrivalTime: 31 Mar 2007 00:48:28.0920 (UTC) FILETIME=[4C4DB780:01C7732E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 My apologies to the list!! My last posting contained a very poorly written paragraph that mis-communicated some important points. This posting seeks to correct that by explaining why our historic IPv6 target architecture inadvertently assumes a business model that wars against the successful deployment of an IPv6 Internet and that approaches such as LISP correct that schizophrenia, increasing the probability of a successful Internet deployment outcome.=20 In RFC 1687 (which was an official Boeing corporate position of that era, unlike all of my recent postings, which are solely my own personal opinions and sought to generically represent the large end user) I sought to explain why the natural inclination of the large end user corporation will be to not deploy IPv6 (then called IPng) unless a compelling business reason to adopt it arises. Should such a business reason arise, the natural tendency will be to deploy IPv6 in the most minimal manner possible. The exception, of course, is if IPv6 became associated with a killer app. Because this is yet to occur, IPv6 remains a "hard sell" to the end user. A key part of the reason for this is that the motivations underlying the creation of IPv6 reflect the concerns of our ISP population and those concerns are completely hidden from the end user. Had the IETF's ISPs not told us that there is an Internet scaling problem with BGP, we end users would not have been aware of that fact. Therefore, IPv6 is itself a solution to the ISP's problems into which the end user has no visibility -- nor is there any capability within IPv6 to encourage the end user to want to deploy IPv6 on its own merits. To make matters worse, the IETF's original position for IPv6 addresses was to solely permit PA addresses, requiring the end users to have addresses that were dependent upon ISPs. This is backwards: a law of economics is that businesses support the desires of their customers, rather than the customers supporting the desires of their vendors!! IPv6 also requires the large end users to be willing to needlessly pay a very expensive re-addressing penalty to deploy IPv6 that does not exist for IPv4 (i.e., assuming they had pre-CIDR IPv4 addresses which are inherently PI). Thus, the business model underlying an IPv6-oriented Internet contains very strong incentives to ensure that that an IPv6 deployment will not occur. LISP corrects this. The business model assumed by LISP is not self-defeating and therefore LISP has a substantially better chance of actually being successfully deployed than any model seriously entertained by the IETF since I joined our community in 1992. This is because LISP restricts the Internet solution to the sole community that has any visibility into that problem. The only thing that LISP requires of the end user is to coherently deploy an IP variant -- something the end user is inherently motivated to do. Therefore, LISP is win-win -- it does not demand a community having no awareness of a problem to sacrificially bear the expense of fixing that problem. Appeals to altruism are effective to the extent of self-awareness and economics. It is unreasonable to expect a community to be motivated by issues it does not know exist. For example, why isn't the Internet community altruistically interested in helping the petroleum or electrical industries? After all, we directly rely upon their products. For the same reason, only the Internet community could be expected to be altruistically motivated to help solve the Internet's problems. >The LISP approach also empowers us end users. For example, my coworkers and=20 >I have been telling various IETF mail lists for the past decade that it is=20 >non-negotiable that we will solely accept PI addresses whether or not the=20 >IETF permits a PA-PI address distinction to exist or not. The world's other=20 >largest companies and governments are almost certainly going to make similar=20 >demands. It simply doesn't matter what the IETF thinks about this (and thus=20 >the IETF needs to just deal with it, which it recently appears to be doing)=20 >because it is unlikely that ISPs will lose the business of their largest=20 >customers over their internal addressing requirements (i.e., re-addressing=20 >is very expensive with no attendant business gain). Worse comes to worse,=20 >we will just decree that we are also ISPs because of our huge sizes. LISP=20 >resolves this dispute by making internal addressing irrelevant to anybody=20 >but the corporation (or government or whatever) itself and the ISPs that support it. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Mar 30 21:04: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 1HXS03-0004iv-8H; Fri, 30 Mar 2007 21:03:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXS00-0004iG-Uu for ram@iab.org; Fri, 30 Mar 2007 21:03:20 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXRzz-0006tq-LR for ram@iab.org; Fri, 30 Mar 2007 21:03:20 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 30 Mar 2007 18:03:20 -0700 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 l2V13JJI017175 for ; Fri, 30 Mar 2007 18:03:19 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2V13Iwn014160 for ; Sat, 31 Mar 2007 01:03:18 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com> <474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Unlike IPv6, the underlying LISP business model is not inherently self-defeating Date: Fri, 30 Mar 2007 18:03:33 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1339; t=1175302999; x=1176166999; 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]=20Unlike=20IPv6, =20the=20underlying=20LISP=20bu siness=20model=20is=20not=20inherently=20self-defeating |Sender:=20; bh=4KtmDd0TwtU+OoY8cxUz+7K2r1ZfddOrQTMqnlNnBFA=; b=dJjNZI6j6H+QQxiDmOUTE+cMFaBadeLQ8hPSA0HyZ9hM/6kaaxjNzlY31oeckr/B7AbDfD5M hUE18MWTBfstVMvzchwW5E5V3Hz2MDpbEiom+9PoutAksXzyXHeKmu+k; 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: bb8f917bb6b8da28fc948aeffb74aa17 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 Mar 30, 2007, at 5:48 PM, Fleischman, Eric wrote: > Should such a business > reason arise, the natural tendency will be to deploy IPv6 in the most > minimal manner possible. The exception, of course, is if IPv6 became > associated with a killer app. Because this is yet to occur, IPv6 > remains > a "hard sell" to the end user. Address exhaustion due to supply-chain, proliferation of spimes, etc. will probably become a real issue at some point, however. Do you believe that a LISP-like solution is also suitable for the 'Internet of Things'? Does a LISP-like solution retain the concept of a single global Internet? If not, have we 'outgrown' that concept due to various technical, business, and political reasons? Does a LISP-like solution lend itself to MANET? Is MANET at some point in the foreseeable future going to become the norm, with complete disintermediation between what we now think of as SPs and customers? Is a LISP-like solution the desired end-state, or should it be viewed as more of a transitional mechanism to Something Else? ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 03:47: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 1HXYHC-0005F1-AR; Sat, 31 Mar 2007 03:45:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXYHA-0005CU-TD for ram@iab.org; Sat, 31 Mar 2007 03:45:28 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXYH9-0000hO-KQ for ram@iab.org; Sat, 31 Mar 2007 03:45:28 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 31 Mar 2007 00:45:27 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2V7jRvM028152; Sat, 31 Mar 2007 00:45:27 -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 l2V7jMEi029209; Sat, 31 Mar 2007 07:45:26 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); Sat, 31 Mar 2007 00:45:22 -0700 Received: from [192.168.0.4] ([10.21.100.101]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Mar 2007 00:45:22 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774864@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <60B7DC87-CA3C-40B1-913E-933D04976E5F@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774864@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D4C9242-BC93-43C3-A02E-09ADC3AAE58F@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Incremental Deployment of LISP Date: Sat, 31 Mar 2007 00:45:25 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Mar 2007 07:45:22.0270 (UTC) FILETIME=[896C07E0:01C77368] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=477; t=1175327127; x=1176191127; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=Swum9ldUAzxP1oqcl1LlSnKWOCIM2XvHr8JQx5kslsY=; b=ijnWqcQZ+zobatDFLG+S/44s3aD6C4ai/QIic3p74iJpA1VkNWxJtCqvAqsRbiJnB9yL5gmr pKCK6wGDXs0utKVnSdcpgHHTDwk1tyS0lRVDE5CA//FPu77gYs/hmMY5; 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: 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 > Client resolves a FQDN for a service, and ITR 1) resolves a > FQDN for the ETR, then 2) resolves the FQDN for the service, > then 3) returns the results of the latter to the client. > > Yes - this means that I expect the client's DNS server to > be co-located with the ITR. And I would expect the DNS server would have to be a configured locator address or else the ITR can't reach it. Which means the DNS servers need to be allocated out of PA space. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 03:58:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXYTX-00079A-2O; Sat, 31 Mar 2007 03:58:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXYTV-00075V-JT for ram@iab.org; Sat, 31 Mar 2007 03:58:13 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXYTU-0002r2-8s for ram@iab.org; Sat, 31 Mar 2007 03:58:13 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 31 Mar 2007 00:58:12 -0700 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 l2V7wB0x032232; Sat, 31 Mar 2007 00:58:11 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2V7wBMF008170; Sat, 31 Mar 2007 07:58:11 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); Sat, 31 Mar 2007 00:58:11 -0700 Received: from [192.168.0.4] ([10.21.100.101]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Mar 2007 00:58:10 -0700 In-Reply-To: <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8396DEF5-F51B-4D05-A1AA-67BE6B8C3D22@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Incremental Deployment of LISP Date: Sat, 31 Mar 2007 00:58:12 -0700 To: Ross Callon X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Mar 2007 07:58:11.0036 (UTC) FILETIME=[53A469C0:01C7736A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2640; t=1175327891; x=1176191891; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=rZ/jA1q5l7qBJSUEO5SkwmtpVA63XSD04VjxtCCvm6Q=; b=cxnWtudAoAdBbZnTFBrg+XT++Jrlt2WGnZe1TOB0QHYFI/eByd0vlrIr8GQGenNeICDbsQI8 FjBJwlktnKwF4szFZ9Mqp3TUffSmYFnsLqx5u+lM7GKn8emqxlokveNl; 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: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Templin, Fred L" , 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 > How is a router supposed to know which packets are using an > address that is available in the global BGP top-level routing table > (such as a PA address), and which packets are using an address > that needs to be mapped? If it is not in the FIB, then the DA is an EID and needs to be mapped. If it's in the FIB, you can route it to it's destination. This *could* be a default setting at the start. > For those routers that are in the default-free core of the Internet > this might be easy: If you have a route, then use it. Else map. > Of course these routers are probably large enough that the ratio > between the speed of the data plane and the speed of the > control plane is so large (perhaps in many cases a factor of > 10,000 or greater) that you don't want them receiving any > control packets specific to LISP, or at least any one control > packet that they do receive better correspond to at least > 10,000 data packets, on average. To me this implies that you > want to push the mapping function outside of the default free > core of the Internet. If you use DHTs or Push, you don't cross the control-plane and data- plane. When you use LISP 1 and 1.5, and can push the ETRs close to the edges where the host systems will be, then the number of mapping requests is spread out for the site. > However, for many routers they will have a default route, and > will not have the full global BGP routing table. I am thinking that > the routers where you might want to do LISP will mostly (or > perhaps entirely?) have a default route for most remote > locations. Thus, if a packet has a destination address that > matches the default route it *might* be a PA address and > *might* be a PI address. It doesn't matter which one it is. If either is in the BGP core routing table it can be routed. If a site uses a PI and wants to withdraw it permanently from the BGP core, it then deploys an ETR. The advantage of copying the inner DA to the outer DA is that you can find the ETR when the route is withdrawn or you find the host when it is not. A protocol unreachable from a host can tell an ITR that the EID is to not be mapped. > Is the thought to partition the address space? The only other > solution that I have thought of is to have strictly controlled > topology (so that there is a clear boundary where the mapping > is done). Not partition one address space, but create a new one, the EID address space. But keep the DNS A records associate with the new address space. And the existing address space in the BGP core are the Locators. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 04:13: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 1HXYhx-0004yD-4K; Sat, 31 Mar 2007 04:13:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXYhv-0004sj-Ks for ram@iab.org; Sat, 31 Mar 2007 04:13:07 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXYht-0006QY-8y for ram@iab.org; Sat, 31 Mar 2007 04:13:07 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Mar 2007 01:13:00 -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 l2V8D0oO001282; Sat, 31 Mar 2007 01:13:00 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l2V8CwEi006222; Sat, 31 Mar 2007 08:13:00 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); Sat, 31 Mar 2007 01:12:57 -0700 Received: from [192.168.0.4] ([10.21.100.101]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Mar 2007 01:12:57 -0700 In-Reply-To: References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96C5E0BB-831A-4824-8F04-535379A25B38@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Date: Sat, 31 Mar 2007 01:13:00 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Mar 2007 08:12:57.0488 (UTC) FILETIME=[64024100:01C7736C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3367; t=1175328780; x=1176192780; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20ICMP=20error=20dependency=20in=20LISP=20(was=3A=20Inc remental=20Deployment=20of=20LISP) |Sender:=20; bh=tHTHgr6BkihS46j0DpDts+Rf4qHCcR2SWzYaO9F6DcA=; b=ba3Z6ZFw6tC1WyJUPOBdp5G1acPF4RDrPeJYzB1is8mY/2rIgXShdFDUSh2x8eh1tXikT66I WiWVS5Vr+Z4GDGZp3YQ0X5MCWIiVMgSCJZIdxSjO8uaXT03Bb/W6Vc4L/XfwJxNFd/Wx47kMSi HV+F/IhhTGVDlV5cwYpMS7YOk=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Margaret Wasserman , ram@iab.org Subject: [RAM] Re: ICMP error dependency in LISP (was: Incremental Deployment of LISP) 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 >> In LISP 1 and 1.5, when the inner DA is copied to the outer DA in >> the ITR and there is no ETR, the destination host will return an >> ICMP Protocol Unreachable message. > > What are the fallbacks if: > > a) A transit router has no route to the destination for whatever > reasons, but does have a default discard route and does not > generate ICMP errors for packets which match that route? > [personally I don't think this is necessarily a very serious > problem because this happens with current routing as well] If ICMP messages are not returned, the ITR cannot detect unreachability. If you try to solve this by having the ITR poll, there will be too many messages and it won't scale. > b) the destination implementation just doesn't send out Protocol > Unreachables for unknown protocols? (not sure how common this is) This would look just like an ETR or a transit router not returning any ICMP messages. There is not much you can do. You *could* monitor return traffic if you have path symmetry. > c) the destination (host?) is currently rate-limiting ICMP error > generation (mandated by the specification) and the ICMP error is > not sent? [e.g., this is why you couldn't build this ICMP error > generation dependency between two routers either; routers are > actually even more busy with their ICMP error generation and more > likely to not send the error] The Internet is best-effort, we are not trying to make datagram delivery more reliable. If a EID mapping has multiple locators and the ETR indicates the priority of each locator is the same, the ITR can load-split traffic among the locators. > d) some poor firewall or ACL filters out the ICMP message at the ICMP > originator's domain, in transit, or at the recipient's domain? The protocol needs feedback. If you choose UDP to return the mapping or error message, those could get filtered as well. There is no magic here, you have to fix the filters. If we let these things get in the way, nothing will be able to get deployed. > e) the ICMP error gets lost in the network (transient routing loop, > congestion, etc.). ICMP delivery is after all unreliable. Oh well, would you rather have a TCP connection between active ITR/ ETR pairs, I don't think so. ARP requests and replies are unreliable. DNS requests and replies are unreliable. SNMP packets are unreliable. We have lived with this. The Internet is best-effort and I think it does a good job of being "best". > While participating in Transport Area working groups (e.g., TCPM) > I've had an.. opportunity to hear rants about ICMP, for example, > that it should be considered completely optional and anything that > requires ICMP to work is broken; at best, ICMP should be an > optimization mechanism. What would you suggest as an alternative that won't have the same issues? > I'm not sure if I completely agree with these, but for sure I > wouldn't built a system that had a very strong requirement for ICMP > error generation and propagation. The messages were defined originally to be of value. Yes, they have been abused over the years, but the intent of the original designers was to help the network. The LISP authors plan to continue to use ICMP. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 04:19:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXYna-0001qZ-Op; Sat, 31 Mar 2007 04:18:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXYnZ-0001qU-RM for ram@iab.org; Sat, 31 Mar 2007 04:18:57 -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 1HXYnX-0007Lw-H3 for ram@iab.org; Sat, 31 Mar 2007 04:18:57 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2007 01:18:55 -0700 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 l2V8It8w029345; Sat, 31 Mar 2007 01:18:55 -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 l2V8IsEi007460; Sat, 31 Mar 2007 08:18:54 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); Sat, 31 Mar 2007 01:18:53 -0700 Received: from [192.168.0.4] ([10.21.100.101]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Mar 2007 01:18:53 -0700 In-Reply-To: <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> 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] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sat, 31 Mar 2007 01:18:56 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Mar 2007 08:18:53.0708 (UTC) FILETIME=[38551CC0:01C7736D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1757; t=1175329135; x=1176193135; 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]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=X09mKGDVORO3h3HCyYJG+8LSF7xsebiasmqjYijHE8Q=; b=SBkA18bydKPxmvawqdeubH5uKxIdwwHSmZR6YayekTpQMYez+LWSEgRkdNRyLLBWGErzDogc fWNuYkJ2RWfHapLeuouU0LXc1aKWaewgtKPcz+vPq7iGPgNpDCGNQIG2; 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: 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 >>> ok, so in this case the intermediate ISP should know that two (or >>> more) locators are equivalent (i.e. they are associated to the >>> same identifier (or potentially set of identifiers)), right? >> >> I don't know what you mean. The TE-ITR only needs to route on the >> outer DA so it would only need a FIB route that the DA would match. >> > > > agree > the question is where does the information about the equivalent > destinations comes from Still can't understand what you are asking. >> No, it is the same way an ISP routes data for a set of prefixes >> across an IGP shortcut MPLS LSP. >> > >> This is the same problem just using an IP tunnel to move large >> number of flows from going to one egress point to another. >> > > right, so what is the benefit added by LISP? Not all ISPs use MPLS. They want to keep OpEx down, so less protocols allow them to do that. You might want to do TE between ISP A and ISP C, where ISP B is between them. MPLS isn't used across ASes. > I mean you can do tunnels to change large amount of flows within a > set of ISPs today, without LISP right? This is true. But they could use a mapping agent to make it more dynamic than what they now. Today, they *could* use GRE tunnels and run BGP over them as well. > I understood that the benefit provided by LISP is that you would be > able to do this autmatically because the intermediate ISP would be > able to learn the equivalent classes of locators automatically > without needing to do any manual configuration, but it seems this > is not the case... It can be dyanmic with respect to having ETRs configured with mappings that steer traffic to a new set of locators. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 05:25:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXZnT-00052S-TO; Sat, 31 Mar 2007 05:22:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXZnR-00052L-NI for ram@iab.org; Sat, 31 Mar 2007 05:22:53 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXZnQ-0000jH-4M for ram@iab.org; Sat, 31 Mar 2007 05:22:53 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E95A4BF461; Sat, 31 Mar 2007 11:22:50 +0200 (CEST) Received: from [163.117.203.101] (unknown [163.117.203.101]) by smtp03.uc3m.es (Postfix) with ESMTP id 79CB2BD730; Sat, 31 Mar 2007 11:22:49 +0200 (CEST) In-Reply-To: References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sat, 31 Mar 2007 11:22:46 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 El 31/03/2007, a las 10:18, Dino Farinacci escribi=F3: >>>> ok, so in this case the intermediate ISP should know that two (or=20= >>>> more) locators are equivalent (i.e. they are associated to the same=20= >>>> identifier (or potentially set of identifiers)), right? >>> >>> I don't know what you mean. The TE-ITR only needs to route on the=20 >>> outer DA so it would only need a FIB route that the DA would match. >>> >> >> >> agree >> the question is where does the information about the equivalent=20 >> destinations comes from > > Still can't understand what you are asking. > i see, maybe we have different assumptions... In order to do TE based on tunnels, the router that is doing that, must=20= be able to decide that all packets with destination address IPA should=20= be forwarded through the tunnel with destination address IPB. For example, if we have a multihomed site with RLOC IPA and IPB, an=20 intermediate router could try to do some TE and tunnel all packets=20 going to IPA into a tunnel going to IPB. This is similar to what they=20 do today, by selecting one or the other route announced by BGP by the=20 multihomed site so, in order to do this tunnel, the router must know that IPA and IPB=20 are two locators that can be used to reach the multihomed site, and=20 then configure the tunnel my question is how does the router in the intermediate ISP learns that=20= IPA and IPB are two locators of the multihomed site? Please note that there are other criteria to select the inner and outer=20= destiantion addresses of the TE tunnel, and this is one example, but in=20= any case, the intermediate ISP must somehow learn what address/prefixes=20= match in order to perform the TE tunnelling If this is done manually, my point is that you can do this today, by=20 manually configuring tunnels, so i don't understand what LISP is adding=20= to all this... more below... > >> I mean you can do tunnels to change large amount of flows within a=20 >> set of ISPs today, without LISP right? > > This is true. But they could use a mapping agent to make it more=20 > dynamic than what they now. exactly do this mapping agent is part of LISP? how does this mapping agent learns the tunnel configurations? > Today, they *could* use GRE tunnels and run BGP over them as well. > >> I understood that the benefit provided by LISP is that you would be=20= >> able to do this autmatically because the intermediate ISP would be=20 >> able to learn the equivalent classes of locators automatically=20 >> without needing to do any manual configuration, but it seems this is=20= >> not the case... > > It can be dyanmic with respect to having ETRs configured with mappings=20= > that steer traffic to a new set of locators. > exactly but in this case, they must be able to learn dynamically which=20 addresses match with which address, so they can create the tunnels=20 dynamically Regards, marcelo PS: I will on the road for a few days, so i am not sure if i will be=20 able to read email, but fwiw, i think this is one fundamental part of=20 the puzzle that is lacking in all available solutions > Dino > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 06:50: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 1HXb6u-0008RP-PC; Sat, 31 Mar 2007 06:47:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXb6t-0008RK-Ay for ram@iab.org; Sat, 31 Mar 2007 06:47:03 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXb6r-0005mM-RN for ram@iab.org; Sat, 31 Mar 2007 06:47:03 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AA4CC177FC3; Sat, 31 Mar 2007 12:47:00 +0200 (CEST) Received: from [163.117.203.101] (unknown [163.117.203.101]) by smtp01.uc3m.es (Postfix) with ESMTP id 2B8F2177F8A; Sat, 31 Mar 2007 12:46:57 +0200 (CEST) In-Reply-To: <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Incremental Deployment of LISP Date: Sat, 31 Mar 2007 12:46:57 +0200 To: Ross Callon X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "Templin, Fred L" , 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 El 30/03/2007, a las 22:47, Ross Callon escribi=F3: > At 07:19 PM 3/30/2007 +0200, Eliot Lear wrote: >> Hi Fred, >>> You seem to be assuming that the mapping will be driven by >>> the first packet out the door; I'm not assuming that at all. >>> For inter-site communications, there will always be an initial >>> FQDN-to-locator resolution before a session starts, and the >>> mapping can be done then before any packets are sent. >> >> Sorry, Yes. I had my head in LISP, where really there is no end host=20= >> interaction. I think that's a good thing, in as much as it becomes=20= >> deployable faster due to a smaller set of processors being touched. =20= >> But in a context, say, like HIP, you would want to do that exact=20 >> resolution for a HIT. >> >> Eliot > > This is beginning to hint at something that I have wondered about > for a while: > > It seems to me that there could be cases where a router (perhaps > in a private network, or a CE router, or perhaps even a PE router) > receives some packets that already use a PA address, and some > that are using a PI address and that need to be encapsulated. > For example this might occur because deployment of LISP is not > precisely equally rapid in each private network, or is not equally > rapid in each site within a larger private network. > > How is a router supposed to know which packets are using an > address that is available in the global BGP top-level routing table > (such as a PA address), and which packets are using an address > that needs to be mapped? I think this heavily depends on what scenario you are considering in LISP 1 doesn't matter, since both identifiers and locators are=20 routable So, if you do have an alternative locator for the identifier, then=20 tunnel, else, forward directly similar in LISP 1.5 In LISP 2 and 3 the issue you are considering needs to be considered=20 imho probably it will induce additional latency, since you probably want to=20= check if the dest address is an identifier. in LISP 3 it depends wheter you are using the push or pull model if you have all the identifier to locator database available, then you=20= can check on it to verify if the destination is a identifier and which=20= are the locators if you don't have it, well, then you need to make a query and find out,=20= which will take additional delay > > Is the thought to partition the address space? The only other > solution that I have thought of is to have strictly controlled > topology (so that there is a clear boundary where the mapping > is done). > yes, this is what HIP people have done, they defined a prefix for the=20 ORCHIDs which are the identifier. probably hip people can expand on this one, but i think it was mostly=20 for allowing transparent support for upper layers Regards, marcelo > Thanks, Ross > > _______________________________________________ > 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 Sat Mar 31 06:50: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 1HXb87-0000Q5-2M; Sat, 31 Mar 2007 06:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXb85-0000On-Vr for ram@iab.org; Sat, 31 Mar 2007 06:48:17 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXb82-000617-Lc for ram@iab.org; Sat, 31 Mar 2007 06:48:17 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Mar 2007 12:48:14 +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 l2VAmDXU014546; Sat, 31 Mar 2007 12:48:13 +0200 Received: from [212.254.247.3] (ams3-vpn-dhcp4135.cisco.com [10.61.80.38]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2VAm8lZ021697; Sat, 31 Mar 2007 10:48:09 GMT Message-ID: <460E3C68.3010505@cisco.com> Date: Sat, 31 Mar 2007 12:48:08 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Ross Callon Subject: Re: [RAM] Incremental Deployment of LISP References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> In-Reply-To: <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> 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=1044; t=1175338093; x=1176202093; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=lzjZh788ArMua+68Kx6r67W13dow/gSygWUDdo6Ngqk=; b=kiz4BcOW/fEsqUwkgSLmiNuhp5wn0Ay6TFxM1qgFUeanrD8ofenbRKFJYvT9kX0D1K+IWJsB ZsDhBkby/L6h0Mw/g2yWs/bbtr6dN/gBECmpgBrlPeXkaLrPwNiI2QzD; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "Templin, Fred L" , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXb6u-0008RP-PC; Sat, 31 Mar 2007 06:47:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXb6t-0008RK-Ay for ram@iab.org; Sat, 31 Mar 2007 06:47:03 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXb6r-0005mM-RN for ram@iab.org; Sat, 31 Mar 2007 06:47:03 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AA4CC177FC3; Sat, 31 Mar 2007 12:47:00 +0200 (CEST) Received: from [163.117.203.101] (unknown [163.117.203.101]) by smtp01.uc3m.es (Postfix) with ESMTP id 2B8F2177F8A; Sat, 31 Mar 2007 12:46:57 +0200 (CEST) In-Reply-To: <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Incremental Deployment of LISP Date: Sat, 31 Mar 2007 12:46:57 +0200 To: Ross Callon X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "Templin, Fred L" , 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 El 30/03/2007, a las 22:47, Ross Callon escribi=F3: > At 07:19 PM 3/30/2007 +0200, Eliot Lear wrote: >> Hi Fred, >>> You seem to be assuming that the mapping will be driven by >>> the first packet out the door; I'm not assuming that at all. >>> For inter-site communications, there will always be an initial >>> FQDN-to-locator resolution before a session starts, and the >>> mapping can be done then before any packets are sent. >> >> Sorry, Yes. I had my head in LISP, where really there is no end host=20= >> interaction. I think that's a good thing, in as much as it becomes=20= >> deployable faster due to a smaller set of processors being touched. =20= >> But in a context, say, like HIP, you would want to do that exact=20 >> resolution for a HIT. >> >> Eliot > > This is beginning to hint at something that I have wondered about > for a while: > > It seems to me that there could be cases where a router (perhaps > in a private network, or a CE router, or perhaps even a PE router) > receives some packets that already use a PA address, and some > that are using a PI address and that need to be encapsulated. > For example this might occur because deployment of LISP is not > precisely equally rapid in each private network, or is not equally > rapid in each site within a larger private network. > > How is a router supposed to know which packets are using an > address that is available in the global BGP top-level routing table > (such as a PA address), and which packets are using an address > that needs to be mapped? I think this heavily depends on what scenario you are considering in LISP 1 doesn't matter, since both identifiers and locators are=20 routable So, if you do have an alternative locator for ab.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Ross, > How is a router supposed to know which packets are using an > address that is available in the global BGP top-level routing table > (such as a PA address), and which packets are using an address > that needs to be mapped? I guess the way I would tackle this problem is by first attempting to find a mapping. Failing that I would fall back on the global routing table as it is today. To me this says, "Assume things are the way they are today (baseline) unless told differently". That's safe. Remember when BGP4 was deployed. CIDR was out there first. Well, here we would have this table populated first (except for test cases). There are two prices for doing it this way: * A mandatory extra lookup in an additional table * Wide distribution of the mapping table through some as of yet undetermined means. This thing will need to be MORE reliable and scale more broadly than the root servers. Given this, I don't think it matters where the address space comes from. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram the identifier, then=20 tunnel, else, forward directly similar in LISP 1.5 In LISP 2 and 3 the issue you are considering needs to be considered=20 imho probably it will induce additional latency, since you probably want to=20= check if the dest address is an identifier. in LISP 3 it depends wheter you are using the push or pull model if you have all the identifier to locator database available, then you=20= can check on it to verify if the destination is a identifier and which=20= are the locators if you don't have it, well, then you need to make a query and find out,=20= which will take additional delay > > Is the thought to partition the address space? The only other > solution that I have thought of is to have strictly controlled > topology (so that there is a clear boundary where the mapping > is done). > yes, this is what HIP people have done, they defined a prefix for the=20 ORCHIDs which are the identifier. probably hip people can expand on this one, but i think it was mostly=20 for allowing transparent support for upper layers Regards, marcelo > Thanks, Ross > > _______________________________________________ > 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 Sat Mar 31 06:50: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 1HXb87-0000Q5-2M; Sat, 31 Mar 2007 06:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXb85-0000On-Vr for ram@iab.org; Sat, 31 Mar 2007 06:48:17 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXb82-000617-Lc for ram@iab.org; Sat, 31 Mar 2007 06:48:17 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 31 Mar 2007 12:48:14 +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 l2VAmDXU014546; Sat, 31 Mar 2007 12:48:13 +0200 Received: from [212.254.247.3] (ams3-vpn-dhcp4135.cisco.com [10.61.80.38]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2VAm8lZ021697; Sat, 31 Mar 2007 10:48:09 GMT Message-ID: <460E3C68.3010505@cisco.com> Date: Sat, 31 Mar 2007 12:48:08 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Ross Callon Subject: Re: [RAM] Incremental Deployment of LISP References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> In-Reply-To: <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> 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=1044; t=1175338093; x=1176202093; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=lzjZh788ArMua+68Kx6r67W13dow/gSygWUDdo6Ngqk=; b=kiz4BcOW/fEsqUwkgSLmiNuhp5wn0Ay6TFxM1qgFUeanrD8ofenbRKFJYvT9kX0D1K+IWJsB ZsDhBkby/L6h0Mw/g2yWs/bbtr6dN/gBECmpgBrlPeXkaLrPwNiI2QzD; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "Templin, Fred L" , 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 Ross, > How is a router supposed to know which packets are using an > address that is available in the global BGP top-level routing table > (such as a PA address), and which packets are using an address > that needs to be mapped? I guess the way I would tackle this problem is by first attempting to find a mapping. Failing that I would fall back on the global routing table as it is today. To me this says, "Assume things are the way they are today (baseline) unless told differently". That's safe. Remember when BGP4 was deployed. CIDR was out there first. Well, here we would have this table populated first (except for test cases). There are two prices for doing it this way: * A mandatory extra lookup in an additional table * Wide distribution of the mapping table through some as of yet undetermined means. This thing will need to be MORE reliable and scale more broadly than the root servers. Given this, I don't think it matters where the address space comes from. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 12:26:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXgMJ-0001iv-RK; Sat, 31 Mar 2007 12:23:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXgMI-0001hb-Nn for ram@iab.org; Sat, 31 Mar 2007 12:23:18 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXgMH-0007JP-1C for ram@iab.org; Sat, 31 Mar 2007 12:23:18 -0400 Received: from [192.168.0.100] (c-24-6-155-154.hsd1.ca.comcast.net[24.6.155.154]) by comcast.net (sccrmhc13) with SMTP id <20070331162315013003gdh1e>; Sat, 31 Mar 2007 16:23:16 +0000 In-Reply-To: References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sat, 31 Mar 2007 09:23:16 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) 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 Mar 31, 2007, at 2:22 AM, marcelo bagnulo braun wrote: > i think this is one fundamental part of the puzzle that is lacking > in all available solutions I'm not yet convinced that this is really a requirement. Consider what you're asking: the ability to TE on a per-site basis, given that traffic is already assigned to PA prefixes. Typically in the past, ISPs have wanted to do TE within another providers prefix, and thus we have more specifics. This is incredibly important for managing peering ratios and the like. However, applying TE on multi-homed PI sites seems like it would be much less important requirement. Am I confused? Any operators in the forum, please speak up... Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 14:58: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 1HXijI-0001bp-RT; Sat, 31 Mar 2007 14:55:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXijI-0001bj-2u for ram@iab.org; Sat, 31 Mar 2007 14:55: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 1HXij5-000594-G2 for ram@iab.org; Sat, 31 Mar 2007 14:55:12 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l2VIeY61025606; Sat, 31 Mar 2007 10:40:49 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Sat, 31 Mar 2007 19:54:20 +0100 X-PGP-Universal: processed; by terminus.local on Sat, 31 Mar 2007 19:54:20 +0100 In-Reply-To: <460D253A.100@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP Date: Sat, 31 Mar 2007 19:53:10 +0100 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Mar 30, 2007, at 3:56 PM, Eliot Lear wrote: > Lookups are a non-starter because of the lookup latency and what > you do with a packet on a cache miss I wonder if the folks who argued against moving from HOSTS.TXT to the DNS used the same rationale... :-) More seriously, the vast majority of people and processes already have to deal with lookup latency on the initiation of an Internet transaction since IP addresses aren't generally used by people or applications. As for what to do with cache misses, you do the same thing you do with any datagram-based system: you buffer and when you can't buffer you drop based on some algorithm and assume the packet will be retransmitted. If you have the mapping service at the edge, you don't need to use static RAM, but instead can use cheap commodity DRAM and have a really big cache. > We want something that is akin to the RADB (perhaps a big table > that can be diffed periodically), but to be sure is administered > easily by end systems. I don't think this is what we want. I could see an argument for a dynamic table of identifier to locator mappings similar to the routing table being propagated by flooding. I could even see an argument for something done along the lines of P2P file sharing apps like BitTorrent. I could (of course) see a pull based mechanism that has characteristics similar to the DNS. But something like the centralized, largely static RADB? The security model is wrong. People forget to update it. Who would run/maintain it? Etc. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 15:18: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 1HXj5S-0006AD-9k; Sat, 31 Mar 2007 15:18:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXj5R-0006A8-VK for ram@iab.org; Sat, 31 Mar 2007 15:18:05 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXj5L-0002Ct-AI for ram@iab.org; Sat, 31 Mar 2007 15:18:05 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 37234117098; Sat, 31 Mar 2007 21:17:56 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 1CE771170F7; Sat, 31 Mar 2007 21:17:55 +0200 (CEST) Received: from dyn-88-123-215-220.ppp.tiscali.fr (dyn-88-123-215-220.ppp.tiscali.fr [88.123.215.220]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Sat, 31 Mar 2007 21:17:53 +0200 Message-ID: <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> Date: Sat, 31 Mar 2007 21:17:53 +0200 From: MARCELO BAGNULO BRAUN To: Tony Li Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> In-Reply-To: <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) 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 Tony Li dijo: > > On Mar 31, 2007, at 2:22 AM, marcelo bagnulo braun wrote: > >> i think this is one fundamental part of the puzzle that is lacking >> in all available solutions > > > I'm not yet convinced that this is really a requirement. Consider > what you're asking: the ability to TE on a per-site basis, given that > traffic is already assigned to PA prefixes. Typically in the past, > ISPs have wanted to do TE within another providers prefix, and thus > we have more specifics. This is incredibly important for managing > peering ratios and the like. However, applying TE on multi-homed PI > sites seems like it would be much less important requirement. > but this seems to be the only difference from the operator perspective, between a PI-BGP based multihoming solution and a multihoming solution based on PA and an host based mechanism like HIP or shim. since the ISPs claim that there is some TE functionalities missing, it zould be important to understand what are those so ze can actually provide those... regards, marcelo > Am I confused? Any operators in the forum, please speak up... > > Tony > > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 19:21: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 1HXmqD-0006wj-EV; Sat, 31 Mar 2007 19:18:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXmqC-0006wc-F6 for ram@iab.org; Sat, 31 Mar 2007 19:18:36 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXmq3-0006M5-6l for ram@iab.org; Sat, 31 Mar 2007 19:18:36 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 31 Mar 2007 16:18:24 -0700 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 l2VNIMwL019003; Sat, 31 Mar 2007 16:18:22 -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 l2VNILZT010706; Sat, 31 Mar 2007 23:18:22 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); Sat, 31 Mar 2007 16:18:21 -0700 Received: from [192.168.0.100] ([10.21.80.250]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Mar 2007 16:18:20 -0700 In-Reply-To: <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4FC4F032-5B75-4053-9059-9466FAF603B0@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sat, 31 Mar 2007 16:18:22 -0700 To: MARCELO BAGNULO BRAUN X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 31 Mar 2007 23:18:20.0998 (UTC) FILETIME=[DF580E60:01C773EA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1277; t=1175383102; x=1176247102; 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]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=oSQu/5J/bcThZLf3lZNWB5q+oxVZvEqGf0u7rhCTCW4=; b=e92mx+cC9QRi+cAbSQhU6GVUPvR2Le0i8Lmgzkf5uM4dvZb0at3yTeHYWXnLwoNpGfS4O8Bk v1/swNIMv1IilmJ26uKq3tILx9EdKGkvfGjluFRs3yy9S/zd0aW/j8Wo; 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: 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'm not yet convinced that this is really a requirement. >> Consider what you're asking: the ability to TE on a per-site >> basis, given that traffic is already assigned to PA prefixes. >> Typically in the past, ISPs have wanted to do TE within another >> providers prefix, and thus we have more specifics. This is >> incredibly important for managing peering ratios and the like. >> However, applying TE on multi-homed PI sites seems like it would >> be much less important requirement. > > but this seems to be the only difference from the operator > perspective, between a PI-BGP based multihoming solution and a > multihoming solution based on PA and an host based mechanism like > HIP or shim. Not necessarily. Consider an ITR/ETR co-located with a PE router. That's very interesting from an operator perspective as they can then effectively change locators for a site without site intervention. > since the ISPs claim that there is some TE functionalities missing, > it zould be important to understand what are those so ze can > actually provide those... I agree. Moreover, it's important that we confirm that the features that we are providing are those that are beneficial. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 21:35: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 1HXovS-0004eT-C3; Sat, 31 Mar 2007 21:32:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXovR-0004eG-JV for ram@iab.org; Sat, 31 Mar 2007 21:32:09 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXovQ-0005rn-AI for ram@iab.org; Sat, 31 Mar 2007 21:32:09 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 31 Mar 2007 18:32:08 -0700 X-IronPort-AV: i="4.14,357,1170662400"; d="scan'208"; a="700279939:sNHT32843496" Received: from rcallon-lt1.juniper.net ([172.23.1.243]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l311VxJ23271; Sat, 31 Mar 2007 18:31:59 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070331205700.033d1290@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 31 Mar 2007 21:31:37 -0400 To: Tony Li , ram@iab.org From: Ross Callon Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) In-Reply-To: <4FC4F032-5B75-4053-9059-9466FAF603B0@cisco.com> References: <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 At 04:18 PM 3/31/2007 -0700, Tony Li wrote: >...Not necessarily. Consider an ITR/ETR co-located with a PE router. >That's very interesting from an operator perspective as they can then >effectively change locators for a site without site intervention. I apologize for repeating myself, but I haven't seen an answer to this... Several of the PE routers that I have been looking at recently (from multiple vendors) seem to have a data plane that operates at a rate that is a small number of hundreds of gigabits per second. They have a link from the data plane to the central processor that is in many cases perhaps 100Mbps (1,000 times slower). The link could of course be a gigabit Ethernet. However it appears that the central processor can't receive a constant stream even of 100Mbps of traffic. Trying to figure out how fast the central processor can actually gobble up (ie, process properly) incoming traffic is a bit more complex, and the answer seems to be "it depends, but a few tens of megabits seems reasonable". Thus there seem to be several possibilities if LISP is going to be deployed on PE routers: (1) You are going to make the data plane MUCH slower; or (2) You are going to very lightly load the data plane; or (3) You are going to implement the control aspects of LISP somewhere other than on the central processor; or (4) You are going to build routers whose central processor is several orders of magnitude faster than on current routers; or (5) You feel that you can implement LISP on a PE router with a load on the control plane which is at least 10,000 times smaller than the load on the data plane (so that each time a packet goes to the control plane, on the average there are 10,000 or more packets that will be forwarded via the data plane before the next packet needs to go to the control plane) I am guessing that the answer is either (5), or perhaps (3), or (6) You are going to deploy LISP closer to the edge (and NOT in the PE router). However, I haven't seen a discussion of this point (my apology if I just missed it, there is of course a LOT of traffic on RAM, and strangely enough there is also other work to be done). Thanks, Ross _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 23:00: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 1HXqG2-0003sx-1p; Sat, 31 Mar 2007 22:57:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXqG1-0003sp-2i for ram@iab.org; Sat, 31 Mar 2007 22:57:29 -0400 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXqG0-0005GU-JO for ram@iab.org; Sat, 31 Mar 2007 22:57:29 -0400 Received: from [134.129.105.135] (dyn135.wireless-105.ndsu.NoDak.edu [134.129.105.135]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id l312vHfW018560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 31 Mar 2007 21:57:18 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <5.0.0.25.2.20070331205700.033d1290@zircon.juniper.net> References: <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> <5.0.0.25.2.20070331205700.033d1290@zircon.juniper.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bruce Curtis Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sat, 31 Mar 2007 21:56:25 -0500 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -2.7 (--) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 had been thinking similarly, the architecture of LISP (or any proxy or middlebox solution that has to create a cache or state based on all traffic) reminds me of IGMP v2. A problem with IGMP v2 is that the switch must snoop at all of the packets from high bandwidth applications like Norton Ghost etc in order to find the few IGMP reports or joins in the stream. In IGMP v3 on the other hand the switch can look at another stream or multicast group that is specifically designed for requests to create state (join or leave a group). On Mar 31, 2007, at 8:31 PM, Ross Callon wrote: > At 04:18 PM 3/31/2007 -0700, Tony Li wrote: >> ...Not necessarily. Consider an ITR/ETR co-located with a PE router. >> That's very interesting from an operator perspective as they can then >> effectively change locators for a site without site intervention. > > I apologize for repeating myself, but I haven't seen an answer to > this... > > Several of the PE routers that I have been looking at recently (from > multiple vendors) seem to have a data plane that operates at a rate > that is a small number of hundreds of gigabits per second. They have > a link from the data plane to the central processor that is in many > cases perhaps 100Mbps (1,000 times slower). The link could of > course be a gigabit Ethernet. However it appears that the central > processor can't receive a constant stream even of 100Mbps of traffic. > Trying to figure out how fast the central processor can actually > gobble up (ie, process properly) incoming traffic is a bit more > complex, and the answer seems to be "it depends, but a few tens > of megabits seems reasonable". > > Thus there seem to be several possibilities if LISP is going to be > deployed on PE routers: > > (1) You are going to make the data plane MUCH slower; or > (2) You are going to very lightly load the data plane; or > (3) You are going to implement the control aspects of LISP > somewhere other than on the central processor; or > (4) You are going to build routers whose central processor is > several orders of magnitude faster than on current routers; or > (5) You feel that you can implement LISP on a PE router > with a load on the control plane which is at least 10,000 > times smaller than the load on the data plane (so that each > time a packet goes to the control plane, on the average there > are 10,000 or more packets that will be forwarded via the data > plane before the next packet needs to go to the control plane) > > I am guessing that the answer is either (5), or perhaps (3), or > (6) You are going to deploy LISP closer to the edge (and NOT > in the PE router). > > However, I haven't seen a discussion of this point (my apology > if I just missed it, there is of course a LOT of traffic on RAM, > and strangely enough there is also other work to be done). > > Thanks, Ross > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 23:15: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 1HXqWn-0003o9-9L; Sat, 31 Mar 2007 23:14:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXqWl-0003nw-WE for ram@iab.org; Sat, 31 Mar 2007 23:14:48 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXqWj-0007xy-KH for ram@iab.org; Sat, 31 Mar 2007 23:14:47 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by kremlin.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 31 Mar 2007 20:14:45 -0700 X-IronPort-AV: i="4.14,357,1170662400"; d="scan'208"; a="679586137:sNHT41171336" Received: from rcallon-lt1.juniper.net ([172.23.1.243]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l313EhJ32334; Sat, 31 Mar 2007 20:14:44 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070331213851.033d0eb0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 31 Mar 2007 21:57:26 -0400 To: marcelo bagnulo braun From: Ross Callon Subject: Re: [RAM] Incremental Deployment of LISP In-Reply-To: <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> References: <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "Templin, Fred L" , 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:46 PM 3/31/2007 +0200, marcelo bagnulo braun wrote: >...in LISP 1 doesn't matter, since both identifiers and locators are routable >So, if you do have an alternative locator for the identifier, then tunnel, >else, forward directly > >similar in LISP 1.5 I agree. In LISP 1.0 and 1.5 this particular point doesn't seem to be an issue, since you route on the IDs (until you are directed to map to something else). >In LISP 2 and 3 the issue you are considering needs to be considered imho > >probably it will induce additional latency, since you probably want to >check if the dest address is an identifier. > >in LISP 3 it depends whether you are using the push or pull model I think that I am assuming that you need a pull model (to get the mapping table) for two reasons (the second is the BIG one): - One is that part of the point of LISP is to make it easier for sites to use PI addresses. If we make it easier for sites to use PI addresses, presumably many will actually do this. This implies that the mapping table is likely to grow considerably more quickly than the current routing table. - For performance reasons, I am assuming that we need to push the encapsulation / decapsulation function relatively close to the edge (note, this is NOT due to the performance of the actual encapsulation, which should be possible to do at line rate -- at least if you are willing to update many or most deployed routers -- this is due to performance of the control plane). If you push this into large enterprises, then the granularity of your forwarding tableFrom ram-bounces@iab.org Sat Mar 31 23:15: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 1HXqWn-0003o9-9L; Sat, 31 Mar 2007 23:14:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXqWl-0003nw-WE for ram@iab.org; Sat, 31 Mar 2007 23:14:48 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXqWj-0007xy-KH for ram@iab.org; Sat, 31 Mar 2007 23:14:47 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by kremlin.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 31 Mar 2007 20:14:45 -0700 X-IronPort-AV: i="4.14,357,1170662400"; d="scan'208"; a="679586137:sNHT41171336" Received: from rcallon-lt1.juniper.net ([172.23.1.243]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l313EhJ32334; Sat, 31 Mar 2007 20:14:44 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070331213851.033d0eb0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 31 Mar 2007 21:57:26 -0400 To: marcelo bagnulo braun From: Ross Callon Subject: Re: [RAM] Incremental Deployment of LISP In-Reply-To: <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> References: <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "Templin, Fred L" , 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:46 PM 3/31/2007 +0200, marcelo bagnulo braun wrote: >...in LISP 1 doesn't matter, since both identifiers and locators are routable >So, if you do have an alternative locator for the identifier, then tunnel, >else, forward directly > >similar in LISP 1.5 I agree. In LISP 1.0 and 1.5 this particular point doesn't seem to be an issue, since you route on the IDs (until you are directed to map to something else). >In LISP 2 and 3 the issue you are considering needs to be considered imho > >probably it will induce additional latency, since you probably want to >check if the dest address is an identifier. > >in LISP 3 it depends whether you are using the push or pull model I think that I am assuming that you need a pull model (to get the mapping table) for two reasons (the second is the BIG one): - One is that part of the point of LISP is to make it easier for sites to use PI addresses. If we make it easier for sites to use PI addresses, presumably many will actually do this. This implies that the mapping table is likely to grow considerably more quickly than the current routing table. - For performance reasons, I am assuming that we need to push the encapsulation / decapsulation function relatively close to the edge (note, this is NOT due to the performance of the actual encapsulation, which should be possible to do at line rate -- at least if you are willing to update many or most deployed routers -- this is due to performance of the control plane). If you push this into large enterprises, then the granularity of your forwarding table for destinations inside large enterprises on the opposite side of the world is much finer than the current IP forwarding table for the same destinations. This means that you probably can't store the entire mapping table all at once in one place. >...if you have all the identifier to locator database available, then you >can check on it to verify if the destination is a identifier and which are >the locators > >if you don't have it, well, then you need to make a query and find out, >which will take additional delay Actually, if you are in the core of the Internet and have the full BGP forwarding table (and NO default route) then you probably do know which addresses are PA, and don't need to do the lookup (which in a terabit router is a relief). For other routers (and of course there are lots of routers in many places that are still quite large, but not in the default-free core), then this would seem to suggest that you are essentially doing cache-based routing, even if the cache is only to determine whether or not you need to map a PI address to a PA address. To me this is relatively more scary than the alternative of partitioning the address space -- although I admit that partitioning all of the address space may be rather difficult to get people to agree to do (it would seem to imply a lot of renumbering). >>Is the thought to partition the address space? The only other >>solution that I have thought of is to have strictly controlled >>topology (so that there is a clear boundary where the mapping >>is done). > >yes, this is what HIP people have done, they defined a prefix for the >ORCHIDs which are the identifier. > >probably hip people can expand on this one, but i think it was mostly for >allowing transparent support for upper layers I could see an approach where existing PI addresses continue to be in the global IP routing table, and only *new* PI addresses come from the special space. Thus only the new PI addresses would be mapped, and we would be able to know that we need to do this because the special part of the IP address space (whether IPv4 or IPv6) is well known. Ross _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 23:15: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 1HXqWn-0003oE-F5; Sat, 31 Mar 2007 23:14:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXqWm-0003o4-Dx for ram@iab.org; Sat, 31 Mar 2007 23:14:48 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXqWl-0007y0-TR for ram@iab.org; Sat, 31 Mar 2007 23:14:48 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 31 Mar 2007 20:14:47 -0700 X-IronPort-AV: i="4.14,357,1170662400"; d="scan'208"; a="700303750:sNHT42446926" Received: from rcallon-lt1.juniper.net ([172.23.1.243]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l313EkJ32337; Sat, 31 Mar 2007 20:14:46 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070331215849.034161c0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 31 Mar 2007 23:14:28 -0400 To: Dino Farinacci From: Ross Callon Subject: Re: [RAM] Incremental Deployment of LISP In-Reply-To: <8396DEF5-F51B-4D05-A1AA-67BE6B8C3D22@cisco.com> References: <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format for destinations inside large enterprises on the opposite side of the world is much finer than the current IP forwarding table for the same destinations. This means that you probably can't store the entire mapping table all at once in one place. >...if you have all the identifier to locator database available, then you >can check on it to verify if the destination is a identifier and which are >the locators > >if you don't have it, well, then you need to make a query and find out, >which will take additional delay Actually, if you are in the core of the Internet and have the full BGP forwarding table (and NO default route) then you probably do know which addresses are PA, and don't need to do the lookup (which in a terabit router is a relief). For other routers (and of course there are lots of routers in many places that are still quite large, but not in the default-free core), then this would seem to suggest that you are essentially doing cache-based routing, even if the cache is only to determine whether or not you need to map a PI address to a PA address. To me this is relatively more scary than the alternative of partitioning the address space -- although I admit that partitioning all of the address space may be rather difficult to get people to agree to do (it would seem to imply a lot of renumbering). >>Is the thought to partition the address space? The only other >>solution that I have thought of is to have strictly controlled >>topology (so that there is a clear boundary where the mapping >>is done). > >yes, this is what HIP people have done, they defined a prefix for the >ORCHIDs which are the identifier. > >probably hip people can expand on this one, but i think it was mostly for >allowing transparent support for upper layers I could see an approach where existing PI addresses continue to be in the global IP routing table, and only *new* PI addresses come from the special space. Thus only the new PI addresses would be mapped, and we would be able to know that we need to do this because the special part of the IP address space (whether IPv4 or IPv6) is well known. Ross _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 23:15: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 1HXqWn-0003oE-F5; Sat, 31 Mar 2007 23:14:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXqWm-0003o4-Dx for ram@iab.org; Sat, 31 Mar 2007 23:14:48 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXqWl-0007y0-TR for ram@iab.org; Sat, 31 Mar 2007 23:14:48 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 31 Mar 2007 20:14:47 -0700 X-IronPort-AV: i="4.14,357,1170662400"; d="scan'208"; a="700303750:sNHT42446926" Received: from rcallon-lt1.juniper.net ([172.23.1.243]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l313EkJ32337; Sat, 31 Mar 2007 20:14:46 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070331215849.034161c0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 31 Mar 2007 23:14:28 -0400 To: Dino Farinacci From: Ross Callon Subject: Re: [RAM] Incremental Deployment of LISP In-Reply-To: <8396DEF5-F51B-4D05-A1AA-67BE6B8C3D22@cisco.com> References: <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: "Templin, Fred L" , 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:58 AM 3/31/2007 -0700, Dino Farinacci wrote: >>How is a router supposed to know which packets are using an >>address that is available in the global BGP top-level routing table >>(such as a PA address), and which packets are using an address >>that needs to be mapped? > >If it is not in the FIB, then the DA is an EID and needs to be >mapped. If it's in the FIB, you can route it to it's destination. >This *could* be a default setting at the start. But I have a default route, so I can always route the packet -- until it gets to the default free core of the Internet. [If the default route doesn't count as "a route", then I can never route the packet (unless it starts in the default free core of the Internet).] >... >If you use DHTs or Push, you don't cross the control-plane and data- >plane. When you use LISP 1 and 1.5, and can push the ETRs close to >the edges where the host systems will be, then the number of mapping >requests is spread out for the site. I am worried about a full PUSH due to the potential size of the mapping table (see the email that I just sent). If you can deploy LISP very close to the host then I agree that this particular problem goes away. >>However, for many routers they will have a default route, and >>will not have the full global BGP routing table. I am thinking that >>the routers where you might want to do LISP will mostly (or >>perhaps entirely?) have a default route for most remote >>locations. Thus, if a packet has a destination address that >>matches the default route it *might* be a PA address and >>*might* be a PI address. > >It doesn't matter which one it is. If either is in the BGP core >routing table it can be routed. If a site uses a PI and wants to >withdraw it permanently from the BGP core, it then deploys an ETR. > >The advantage of copying the inner DA to the outer DA is that you can >find the ETR when the route is withdrawn or you find the host when it >is not. A protocol unreachable from a host can tell an ITR that the >EID is to not be mapped. So the encapsulating router near the source copies the DA into the DA of the extra IP header, and puts its address as the SA of the extra IP header. If the destination doesn't understand LISP, it *might* send back an ICMP protocol unreachable and the encapsulating router knows to send the next packet without encapsulation (and if the destination doesn't have a router that understands LISP, its address better be in the global routing table, which makes sense). Of course this protocol unreachable is very likely handled by the control plane of the encapsulating router, and therefore contributes to my performance concern with deploying LISP in PE routers. If the ICMP protocol unreachable is lost due to a random event, then another packet is sent, the next protocol unreachable gets through, and we are fine. However, if the ICMP protocol unreachable is lost due to permanent reasons -- such as there is a network in the path that has a policy of not allowing them, then either there is a problem, or the encapsulating router has to somehow notice that packets aren't getting through without getting any indication of this (presumably the source host will notice that it doesn't get a reply, but I am not clear on how it would tell the encapsulating router to stop encapsulating, since the source host is not on the path of the encapsulated packet, and therefore does not necessarily know which =flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: "Templin, Fred L" , 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:58 AM 3/31/2007 -0700, Dino Farinacci wrote: >>How is a router supposed to know which packets are using an >>address that is available in the global BGP top-level routing table >>(such as a PA address), and which packets are using an address >>that needs to be mapped? > >If it is not in the FIB, then the DA is an EID and needs to be >mapped. If it's in the FIB, you can route it to it's destination. >This *could* be a default setting at the start. But I have a default route, so I can always route the packet -- until it gets to the default free core of the Internet. [If the default route doesn't count as "a route", then I can never route the packet (unless it starts in the default free core of the Internet).] >... >If you use DHTs or Push, you don't cross the control-plane and data- >plane. When you use LISP 1 and 1.5, and can push the ETRs close to >the edges where the host systems will be, then the number of mapping >requests is spread out for the site. I am worried about a full PUSH due to the potential size of the mapping table (see the email that I just sent). If you can deploy LISP very close to the host then I agree that this particular problem goes away. >>However, for many routers they will have a default route, and >>will not have the full global BGP routing table. I am thinking that >>the routers where you might want to do LISP will mostly (or >>perhaps entirely?) have a default route for most remote >>locations. Thus, if a packet has a destination address that >>matches the default route it *might* be a PA address and >>*might* be a PI address. > >It doesn't matter which one it is. If either is in the BGP core >routing table it can be routed. If a site uses a PI and wants to >withdraw it permanently from the BGP core, it then deploys an ETR. > >The advantage of copying the inner DA to the outer DA is that you can >find the ETR when the route is withdrawn or you find the host when it >is not. A protocol unreachable from a host can tell an ITR that the >EID is to not be mapped. So the encapsulating router near the source copies the DA into the DA of the extra IP header, and puts its address as the SA of the extra IP header. If the destination doesn't understand LISP, it *might* send back an ICMP protocol unreachable and the encapsulating router knows to send the next packet without encapsulation (and if the destination doesn't have a router that understands LISP, its address better be in the global routing table, which makes sense). Of course this protocol unreachable is very likely handled by the control plane of the encapsulating router, and therefore contributes to my performance concern with deploying LISP in PE routers. If the ICMP protocol unreachable is lost due to a random event, then another packet is sent, the next protocol unreachable gets through, and we are fine. However, if the ICMP protocol unreachable is lost due to permanent reasons -- such as there is a network in the path that has a policy of not allowing them, then either there is a problem, or the encapsulating router has to somehow notice that packets aren't getting through without getting any indication of this (presumably the source host will notice that it doesn't get a reply, but I am not clear on how it would tell the encapsulating router to stop encapsulating, since the source host is not on the path of the encapsulated packet, and therefore does not necessarily know which router is doing the encapsulation). Perhaps one answer is to tell people not to set policies to drop ICMP protocol unreachable messages. So, a site decides to withdraw its route from the BGP core and deploys either an ETR, or for performance and redundancy deploys a number of them. Its route is withdrawn. On the other side of the world there is a system that sends a packet to this site. In the past that packet would have followed the default route until it gets to the default free core of the Internet, then it would have been routed via the specific route to the PI address to the destination site. Now since nothing has changed on the other side of the world, I assume that this still follows the default route until it gets to the default free core of the Internet. Is this correct? When the packet gets to the default free core, there is no route. Thus the packet could be mapped at that router (which is probably a big one), or it gets routed to some system somewhere (not necessarily anywhere close to the actual destination), which sends a redirect somewhere. If the latter, then the packet would have needed to be encapsulated by a system that knows how to handle the redirect (assuming that this system is NOT the source host -- the encapsulation provides the address of the system that is going to handle the redirect). To me this implies that the proposal only allows LISP speakers to talk to the system which has withdrawn its address from the global routing system (which is reasonable). Then in the "prior to withdrawal" case the first packet caused a protocol unreachable message, resulting in the exchange discussed above resulting in "normal" (no encapsulation) exchange. In the "after withdrawal" case the first packet had the encapsulation (assuming that the old cache entry that says "do not encapsulate" has timed out) and thus wherever the packet is routed, the redirect has a place to be sent that will know how to handle it. If I am following this correctly, when the route is withdrawn, the first router in the default free core of the Internet either needs to do a lookup into the mapping function, already have the entire mapping table, or have some other place to forward the packet (which might be a bank of big servers that send redirects to the encapsulating routers, or might be the alternate topology for PI addresses from LISP 1.5). I suppose that the first router in the core of the Internet could also send some form of destination unreachable to the encapsulation router, which would then know to do the lookup into a distributed lookup function. Of course some of these options imply a control plane load on the first router in the default free core, and some do not. Perhaps we need a terminology distinction between "a PI address which is in the global routing table -- just like now", and "a PI address that is not in the global routing table, but needs to be mapped to a PA address". Perhaps "Routable PI" (RPI) and "Nonroutable PI" (NPI)? >>Is the thought to partition the address space? The only other >>solution that I have thought of is to have strictly controlled >>topology (so that there is a clear boundary where the mapping >>is done). > >Not partition one address space, but create a new one, the EID >address space. But keep the DNS A records associate with the new >address space. And the existing address space in the BGP core are the >Locators. > >Dino I think that I am beginning to understand this better. Is your EID space just the "Nonroutable PI" space that I was just proposing? I think that some people would use the term "EID" to mean something other than an IP address which is routable within a site but is not routable globally. Thanks, Ross _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram router is doing the encapsulation). Perhaps one answer is to tell people not to set policies to drop ICMP protocol unreachable messages. So, a site decides to withdraw its route from the BGP core and deploys either an ETR, or for performance and redundancy deploys a number of them. Its route is withdrawn. On the other side of the world there is a system that sends a packet to this site. In the past that packet would have followed the default route until it gets to the default free core of the Internet, then it would have been routed via the specific route to the PI address to the destination site. Now since nothing has changed on the other side of the world, I assume that this still follows the default route until it gets to the default free core of the Internet. Is this correct? When the packet gets to the default free core, there is no route. Thus the packet could be mapped at that router (which is probably a big one), or it gets routed to some system somewhere (not necessarily anywhere close to the actual destination), which sends a redirect somewhere. If the latter, then the packet would have needed to be encapsulated by a system that knows how to handle the redirect (assuming that this system is NOT the source host -- the encapsulation provides the address of the system that is going to handle the redirect). To me this implies that the proposal only allows LISP speakers to talk to the system which has withdrawn its address from the global routing system (which is reasonable). Then in the "prior to withdrawal" case the first packet caused a protocol unreachable message, resulting in the exchange discussed above resulting in "normal" (no encapsulation) exchange. In the "after withdrawal" case the first packet had the encapsulation (assuming that the old cache entry that says "do not encapsulate" has timed out) and thus wherever the packet is routed, the redirect has a place to be sent that will know how to handle it. If I am following this correctly, when the route is withdrawn, the first router in the default free core of the Internet either needs to do a lookup into the mapping function, already have the entire mapping table, or have some other place to forward the packet (which might be a bank of big servers that send redirects to the encapsulating routers, or might be the alternate topology for PI addresses from LISP 1.5). I suppose that the first router in the core of the Internet could also send some form of destination unreachable to the encapsulation router, which would then know to do the lookup into a distributed lookup function. Of course some of these options imply a control plane load on the first router in the default free core, and some do not. Perhaps we need a terminology distinction between "a PI address which is in the global routing table -- just like now", and "a PI address that is not in the global routing table, but needs to be mapped to a PA address". Perhaps "Routable PI" (RPI) and "Nonroutable PI" (NPI)? >>Is the thought to partition the address space? The only other >>solution that I have thought of is to have strictly controlled >>topology (so that there is a clear boundary where the mapping >>is done). > >Not partition one address space, but create a new one, the EID >address space. But keep the DNS A records associate with the new >address space. And the existing address space in the BGP core are the >Locators. > >Dino I think that I am beginning to understand this better. Is your EID space just the "Nonroutable PI" space that I was just proposing? I think that some people would use the term "EID" to mean something other than an IP address which is routable within a site but is not routable globally. Thanks, Ross _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 23:24: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 1HXqfv-00084o-6O; Sat, 31 Mar 2007 23:24:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXqfu-00084i-OE for ram@iab.org; Sat, 31 Mar 2007 23:24:14 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXqft-0000LK-FG for ram@iab.org; Sat, 31 Mar 2007 23:24:14 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 31 Mar 2007 20:24:15 -0700 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 l313OCHY015054 for ; Sat, 31 Mar 2007 20:24:12 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l313OCwn022388 for ; Sun, 1 Apr 2007 03:24:12 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <5.0.0.25.2.20070331215849.034161c0@zircon.juniper.net> References: <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <5.0.0.25.2.20070331215849.034161c0@zircon.juniper.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Sat, 31 Mar 2007 20:24:30 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=650; t=1175397852; x=1176261852; c=relaxed/simple; s=sjdkim8002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=1y/SIiusohxsrNsc3mUdHJB8VPMTnQHZeWuC52qoEZU=; b=C2eyXT+xFB2YAzoODIDvdMmPpD1naadGh4QNM7FoLtsdLS6M6nYubq3F9mmutDAywcXQdweW KpormEnEfgJhPWHC9ad02Kb/gKmplVkJabibcIA9HMtC21zmQW1OvL5T; Authentication-Results: sj-dkim-8; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Mar 31, 2007, at 8:14 PM, Ross Callon wrote: > But I have a default route, so I can always route the packet > -- until it gets to the default free core of the Internet. [If the > default route doesn't count as "a route", then I can never > route the packet (unless it starts in the default free core of > the Internet).] Multihomed endpoint networks don't typically take (or are offered) default. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Mar 31 23:40: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 1HXqvC-0007TV-Ry; Sat, 31 Mar 2007 23:40:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXqvC-0007TQ-0y for ram@iab.org; Sat, 31 Mar 2007 23:40:02 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXqvA-0002CH-Pq for ram@iab.org; Sat, 31 Mar 2007 23:40:02 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by kremlin.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 31 Mar 2007 20:40:01 -0700 X-IronPort-AV: i="4.14,357,1170662400"; d="scan'208"; a="679602763:sNHT69710692" Received: from rcallon-lt1.juniper.net ([172.23.1.243]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l313dtJ34904; Sat, 31 Mar 2007 20:39:55 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070331233654.0333a320@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 31 Mar 2007 23:39:51 -0400 To: Roland Dobbins , ram@iab.org From: Ross Callon Subject: Re: [RAM] Incremental Deployment of LISP In-Reply-To: References: <5.0.0.25.2.20070331215849.034161c0@zircon.juniper.net> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <5.0.0.25.2.20070331215849.034161c0@zircon.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 At 08:24 PM 3/31/2007 -0700, Roland Dobbins wrote: >On Mar 31, 2007, at 8:14 PM, Ross Callon wrote: >>...But I have a default route, so I can always route the packet >>-- until it gets to the default free core of the Internet. [If the >>default route doesn't count as "a route", then I can never >>route the packet (unless it starts in the default free core of >>the Internet).] > >Multihomed endpoint networks don't typically take (or are offered) >default. But multihomed endpoint networks *do* receive packets that were transmitted from networks that are not multihomed. This part of the discussion relates to packets that are coming from somewhere, with a destination that is in the multihomed network. The source might be in a single-homed network. Ross _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram