From ram-bounces@iab.org Tue Jun 05 03:29: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 1HvTSo-0002Dd-L4; Tue, 05 Jun 2007 03:28:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTSn-0002DV-Av for ram@iab.org; Tue, 05 Jun 2007 03:28:21 -0400 Received: from mu-out-0910.google.com ([209.85.134.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvTSl-0007rD-Sw for ram@iab.org; Tue, 05 Jun 2007 03:28:21 -0400 Received: by mu-out-0910.google.com with SMTP id g7so1745136muf for ; Tue, 05 Jun 2007 00:28:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=NST8GHdF5Gdw/DYmqCkEH95Tjvl8D39bAvFdwuDy2cziSv5jMH2GgW1srZ4X/vm/e5eotp/cxQPWyFdGrXCFlH89Xdk16ZwKbV4uZ5hxabdkVCk+PPyvDtIt2EqAQeEDD/v8LzqU7ONwAHhs/9HMpXZt+TpjQKfM3f2sXAEaR3w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=cRMi7R63dtenb4sW5vM9qUi8B4mv2Q17HAKO+FDdpwjisnO52TCEXSSzOcYRwesv7damgQktg/AbWnP/ifJ5NMHfLj09ObA0P4K/W6c/DWfPQANfgvA1BT8AG/eH0oSCqAECC/6aJ923GXNfp1G/liqJ5WpdWFoH2G6m7EPliMM= Received: by 10.82.112.3 with SMTP id k3mr8094501buc.1181028498829; Tue, 05 Jun 2007 00:28:18 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id d24sm2875965nfh.2007.06.05.00.28.17; Tue, 05 Jun 2007 00:28:18 -0700 (PDT) Message-ID: <4665108F.5040609@gmail.com> Date: Tue, 05 Jun 2007 09:28:15 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [RAM] [Fwd: I-D ACTION:draft-carpenter-idloc-map-cons-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 -------- Original Message -------- Subject: I-D ACTION:draft-carpenter-idloc-map-cons-01.txt Date: Mon, 04 Jun 2007 15:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : General Identifier-Locator Mapping Considerations Author(s) : B. Carpenter Filename : draft-carpenter-idloc-map-cons-01.txt Pages : 22 Date : 2007-6-4 This document presents various general considerations about the mapping between identifiers and locators at the network and routing level in the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-idloc-map-cons-01.txt _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 05 18:22: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 1HvhPX-0000v2-Ab; Tue, 05 Jun 2007 18:21:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvhPV-0000ux-UT for ram@iab.org; Tue, 05 Jun 2007 18:21:53 -0400 Received: from imo-m19.mx.aol.com ([64.12.137.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvhPU-0005z4-J0 for ram@iab.org; Tue, 05 Jun 2007 18:21:53 -0400 Received: from HeinerHummel@aol.com by imo-m19.mx.aol.com (mail_out_v38_r9.2.) id o.d3c.a07b5f0 (58808); Tue, 5 Jun 2007 18:20:41 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Tue, 5 Jun 2007 18:20:40 EDT Subject: Re: [RAM] [Fwd: I-D ACTION:draft-carpenter-idloc-map-cons-01.txt] To: brian.e.carpenter@gmail.com, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5014 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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="===============0601804468==" Errors-To: ram-bounces@iab.org --===============0601804468== Content-Type: multipart/alternative; boundary="-----------------------------1181082040" -------------------------------1181082040 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 A truly remarkable draft and yet: 3. asks: Is a Split the solution ? while 5.Conclusion requests to decide=20 between Completely versus Partially disjoint namespaces only. I conclude: S= plit=20 is the only possible solution. =20 But for what? Scalability Problem ? Multihoming? User roaming? IMHO, for eliminating the scalability problem at most two additional bytes =20 are needed; not 4; not 16. =20 And I am sure, solutions for multihoming and user roaming will be completel= y=20 different, given that there is no scalability problem any more. =20 Heiner =20 =20 =20 =20 =20 In einer eMail vom 05.06.2007 09:28:53 Westeurop=E4ische Normalzeit schreibt= =20 brian.e.carpenter@gmail.com: -------- Original Message -------- Subject: I-D ACTION:draft-carpenter-idloc-map-cons-01.txt Date: Mon, 04 Jun 2007 15:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : General Identifier-Locator Mapping Considerations Author(s) : B. Carpenter Filename : draft-carpenter-idloc-map-cons-01.txt Pages : 22 Date : 2007-6-4 This document presents various general considerations about the mapping between identifiers and locators at the network and routing level in the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-idloc-map-cons-01.txt _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram =20 -------------------------------1181082040 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
A truly remarkable draft and yet:
3. asks: Is a Split the solution ? while 5.Conclusion requests to=20 decide between Completely versus Partially disjoint namespaces only. I concl= ude:=20 Split is the only possible solution.
 
But for what? Scalability Problem ? Multihoming? User roaming?
IMHO, for eliminating the scalability problem at most two additional by= tes=20 are needed; not 4; not 16.
 
And I am sure, solutions for multihoming and user roaming will be=20 completely different, given that there is no scalability problem any more.
 
Heiner
 
 
 
 
 
In einer eMail vom 05.06.2007 09:28:53 Westeurop=E4ische Normalzeit sch= reibt=20 brian.e.carpenter@gmail.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>--------=20 Original Message --------
Subject: I-D=20 ACTION:draft-carpenter-idloc-map-cons-01.txt
Date: Mon, 04 Jun 2007=20 15:50:02 -0400
From: Internet-Drafts@ietf.org
Reply-To:=20 internet-drafts@ietf.org
To: i-d-announce@ietf.org

A New=20 Internet-Draft is available from the on-line=20 Internet-Drafts
directories.


    Title   = ;=20     : General Identifier-Locator Mapping Considerations
 = ;=20   Author(s)    : B. Carpenter
    Filename&nbs= p;=20   : draft-carpenter-idloc-map-cons-01.txt
    Pages = ;=20       : 22
    Date       = :=20 2007-6-4
   
This document presents various general=20 considerations about the
    mapping between identifiers and=20 locators at the network and routing
    level in the=20 Internet.

A URL for this Internet-Draft=20 is:
http://www.ietf.org/internet-drafts/draft-carpenter-idloc-map-cons-= 01.txt



_______________________________________________
RAM= =20 mailing=20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 
 -------------------------------1181082040-- --===============0601804468== 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 --===============0601804468==-- From ram-bounces@iab.org Wed Jun 06 02:54: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 1HvpPl-0005P2-Ss; Wed, 06 Jun 2007 02:54:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvpPi-0005Ie-1Q for ram@iab.org; Wed, 06 Jun 2007 02:54:38 -0400 Received: from mu-out-0910.google.com ([209.85.134.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvpPg-00086R-NQ for ram@iab.org; Wed, 06 Jun 2007 02:54:38 -0400 Received: by mu-out-0910.google.com with SMTP id g7so54183muf for ; Tue, 05 Jun 2007 23:54:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=VHsV+a+02mKQDEooYS4PGwabQd8XTdpq49Hf1P4plLnBUK7G0dG619sTaHJPt6MqWbM0MxeXREJqC00touRwqb4wp0iWc1C9img3/6cgJJfa39jFpIpdUjv5Lv1XcmbdB9IilIfG3YWuZWVBkA28jBuFY7oTrwxoyyuisrHXt2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Z3IbdlBLCfyCuVLYE2pMb7shS7S/e2A0uoCiVZdLzTU30gBUWzS+4ggDUBHaYh9oafoXbBk9QetK3hn7THYjFi712sI2cjP8pK5DiU9KoLH4CCcj4YWWe+VYL01BnPYgFxK0tf6w2cG8M+IBjgtI/H1sLXp5GoECIEoJqzZ2gx8= Received: by 10.82.123.16 with SMTP id v16mr283286buc.1181112875782; Tue, 05 Jun 2007 23:54:35 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id f7sm5517155nfh.2007.06.05.23.54.34; Tue, 05 Jun 2007 23:54:34 -0700 (PDT) Message-ID: <46665A22.2000304@gmail.com> Date: Wed, 06 Jun 2007 08:54:26 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: HeinerHummel@aol.com Subject: Re: [RAM] [Fwd: I-D ACTION:draft-carpenter-idloc-map-cons-01.txt] 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: 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 2007-06-06 00:20, HeinerHummel@aol.com wrote: > > A truly remarkable draft and yet: > 3. asks: Is a Split the solution ? while 5.Conclusion requests to decide > between Completely versus Partially disjoint namespaces only. Yes, there is a slight structural error in the logic of the draft there. Thanks. > I conclude: Split > is the only possible solution. In a sense that is not the purpose of this draft - I should clarify that the draft assumes the answer is yes. > > But for what? Scalability Problem ? Multihoming? User roaming? > IMHO, for eliminating the scalability problem at most two additional bytes > are needed; not 4; not 16. That doesn't matter as far as the architectural choices go, I think. > > And I am sure, solutions for multihoming and user roaming will be completely > different, given that there is no scalability problem any more. That isn't sure. Once you have a loc-id split, both mh and roaming involve manipulating the locator for a constant id. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 07 11:27: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 1HwJtU-0001Ky-NP; Thu, 07 Jun 2007 11:27:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwJtU-0001Kq-1s for ram@iab.org; Thu, 07 Jun 2007 11:27:24 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwJtS-0007Yg-Pv for ram@iab.org; Thu, 07 Jun 2007 11:27:24 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Jun 2007 11:27:22 -0400 X-IronPort-AV: i="4.16,395,1175486400"; d="scan'208"; a="123048574:sNHT44174862" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l57FRMFS011635; Thu, 7 Jun 2007 11:27:22 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l57FR0C8000890; Thu, 7 Jun 2007 15:27:22 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 11:27:19 -0400 Received: from [10.86.242.178] ([10.86.242.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 11:27:18 -0400 Message-ID: <466823A7.9070906@employees.org> Date: Thu, 07 Jun 2007 11:26:31 -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.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [RAM] [Fwd: I-D ACTION:draft-carpenter-idloc-map-cons-01.txt] References: <46665A22.2000304@gmail.com> In-Reply-To: <46665A22.2000304@gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 15:27:18.0792 (UTC) FILETIME=[55D8A880:01C7A918] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) 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 Hi Brian. I don't understand some of your reasoning ... - "Within its site, A must have an Identifier and Locator that match 1:1 for the convenience of operational staff" Do you really mean 1:1? There needs to be at least one Identifier known to operations staff which maps to a particular locator, but there can be more. Even if a 1:1 mapping were required, I wouldn't understand how you get from "1:1 match" to the conclusion below: "on-site, Identifiers and Locators should not be split". Does "1:1 match" equal "not split" to you? and then in your response to Heinrich Hummel: >> I conclude: Split is the only possible solution. > > In a sense that is not the purpose of this draft - I should > clarify that the draft assumes the answer is yes. ... but above you said "should not be split" ... ? swb _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 07 11:41: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 1HwK7U-00037L-1K; Thu, 07 Jun 2007 11:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwK7T-00037F-3f for ram@iab.org; Thu, 07 Jun 2007 11:41:51 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwK7R-0003vF-TP for ram@iab.org; Thu, 07 Jun 2007 11:41:51 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 8056C86AED; Thu, 7 Jun 2007 11:41:49 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] [Fwd: I-D ACTION:draft-carpenter-idloc-map-cons-01.txt] Message-Id: <20070607154149.8056C86AED@mercury.lcs.mit.edu> Date: Thu, 7 Jun 2007 11:41:49 -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: Scott W Brim > - "Within its site, A must have an Identifier and Locator that match > - 1:1 for the convenience of operational staff" > Do you really mean 1:1? There needs to be at least one Identifier > known to operations staff which maps to a particular locator, but > there can be more. I haven't read the full text of the latest version yet, but this (and I don't know the whole context, maybe it's somehow less restrictive than it sounds) caught my eye. If identifiers and locators have a 1:1 relationship, a variety of things become impossible (such as doing widespread smale-scale multihoming using identifer<->locator bindings, with multiple locators bound to a single identifier). In fact, making that restriction removes much of the value of having separate "locator" and "identifier" namespaces. If A is 1:1 to B, then you can use A all the time, and having B around offers you no value. The only exception to that observation would be if the binding can be changed over time, while remaining restricted to 1:1 bindings. (So that e.g. A could be bound to B at one point, and later A could be bound to C instead.) That would at least support mobility. Still, it's a very crippling restriction, and while it might have some value in operational simplicity, one wonders if the cost in lost potential functionality is not much higher than what it buys you. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 07 12:17: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 1HwKfn-0007Kd-Ni; Thu, 07 Jun 2007 12:17:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKfm-0007Gy-Qh for ram@iab.org; Thu, 07 Jun 2007 12:17:18 -0400 Received: from imo-d03.mx.aol.com ([205.188.157.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKfl-00037P-Kp for ram@iab.org; Thu, 07 Jun 2007 12:17:18 -0400 Received: from HeinerHummel@aol.com by imo-d03.mx.aol.com (mail_out_v38_r9.2.) id x.bfe.17090f12 (33856); Thu, 7 Jun 2007 12:17:07 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Thu, 7 Jun 2007 12:17:06 EDT Subject: Re: [RAM] [Fwd: I-D ACTION:draft-carpenter-idloc-map-cons-01.txt] To: swb@employees.org, brian.e.carpenter@gmail.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5014 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) 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="===============1127688240==" Errors-To: ram-bounces@iab.org --===============1127688240== Content-Type: multipart/alternative; boundary="-----------------------------1181233026" -------------------------------1181233026 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Maybe I don't understand the whole topic: Are we really after a loc/id-spli= t=20 or are we after a "2 locators"-addressing scheme ? =20 Heiner =20 -------------------------------1181233026 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Maybe I don't understand the whole topic: Are we really after a=20 loc/id-split or are we after a "2 locators"-addressing scheme ?
 
Heiner
 -------------------------------1181233026-- --===============1127688240== 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 --===============1127688240==-- From ram-bounces@iab.org Fri Jun 08 03: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 1HwYiw-0001ZC-NW; Fri, 08 Jun 2007 03:17:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYiw-0001Z6-57 for ram@iab.org; Fri, 08 Jun 2007 03:17:30 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwYiu-0001UL-MN for ram@iab.org; Fri, 08 Jun 2007 03:17:30 -0400 Received: by ug-out-1314.google.com with SMTP id m2so947322uge for ; Fri, 08 Jun 2007 00:17:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=G91vcwps33OcpMpCmIA5vSWpuOAv6XFmbWrH1C8jbEUiyDv4PIceM7KNB13ZlgXsfR5Ru1jHg0plQIEJfZnRmPjwLm0e/RrDxw+JL0PXHAEHHC6moNhzux8xSqB50Y83vWAg4/ZKM7Q5VSdoXIP3crEOal7lpccwFhxWq82nMYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=tU7sJ7YSoNFQVR+ap8G8hMx8P+Thf2Bv3WNV0nKljRIWbUKldqatV4YJaofvcSc7n68BzWewPE0s3h8K1WDS5MgfGi03SpaynPiLdTZvsbtmmd1c87bfjMO1KaTBJgkxH3LYpjj0PBGXjoY9qICF2RajGYzGPN4xWcRd4Qpmuc8= Received: by 10.82.178.11 with SMTP id a11mr4717946buf.1181287047618; Fri, 08 Jun 2007 00:17:27 -0700 (PDT) Received: from ?9.159.130.110? ( [195.212.29.187]) by mx.google.com with ESMTP id i4sm4460351nfh.2007.06.08.00.17.26 (version=SSLv3 cipher=RC4-MD5); Fri, 08 Jun 2007 00:17:27 -0700 (PDT) Message-ID: <46690285.20306@gmail.com> Date: Fri, 08 Jun 2007 09:17:25 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Scott W Brim Subject: Re: [RAM] [Fwd: I-D ACTION:draft-carpenter-idloc-map-cons-01.txt] References: <46665A22.2000304@gmail.com> <466823A7.9070906@employees.org> In-Reply-To: <466823A7.9070906@employees.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 Scott, On 2007-06-07 17:26, Scott W Brim wrote: > Hi Brian. I don't understand some of your reasoning ... > > - "Within its site, A must have an Identifier and Locator that match > 1:1 for the convenience of operational staff" I don't think you'll find that text in the current version. It's in the part that I most seriously reworked. Please forget the -00 version. Brian > > Do you really mean 1:1? There needs to be at least one Identifier > known to operations staff which maps to a particular locator, but > there can be more. > > Even if a 1:1 mapping were required, I wouldn't understand how you > get from "1:1 match" to the conclusion below: "on-site, Identifiers > and Locators should not be split". Does "1:1 match" equal "not > split" to you? > > and then in your response to Heinrich Hummel: > > >> I conclude: Split is the only possible solution. > > > > In a sense that is not the purpose of this draft - I should > > clarify that the draft assumes the answer is yes. > > ... but above you said "should not be split" ... ? > > swb > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 08 03:19: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 1HwYlH-0002D9-Si; Fri, 08 Jun 2007 03:19:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYlG-0002D1-Pr for ram@iab.org; Fri, 08 Jun 2007 03:19:54 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwYlG-0002W0-Ax for ram@iab.org; Fri, 08 Jun 2007 03:19:54 -0400 Received: by ug-out-1314.google.com with SMTP id m2so947829uge for ; Fri, 08 Jun 2007 00:19:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=EiC/xW3PbiL3TPF07zAWsU2DHT5tAOeKHetF64NrBfIAZAeTDK9ELp0lfypiQ6vivJjEaLFhhOU0dlCDKgX7tmwX3VPOSpiE0MH502KzUpRP+unoTCuQvJ2Rj966P7KbIAfufHXXgnVzelRrAOnqa7m5+5GvY7+CO8gsIseIuqM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=NNoZHbv/Vxu5H8KzWBgdPlYQLLTz7jGocJWb8qAcPFekPysd4xmkUtqnXVELDhJ1m6/6z9V+OicDGjzeuLkJi/fXlgPgJoCznPt6NjHYJvYlbIfa/F8XQ0nR08lARZ2lqJcu5C+cXCO3PKrPt/Dq9sdd2t1CY6VtIX/4hZJtopA= Received: by 10.82.112.3 with SMTP id k3mr4743519buc.1181287193589; Fri, 08 Jun 2007 00:19:53 -0700 (PDT) Received: from ?9.159.130.110? ( [195.212.29.163]) by mx.google.com with ESMTP id f7sm4362615nfh.2007.06.08.00.19.52 (version=SSLv3 cipher=RC4-MD5); Fri, 08 Jun 2007 00:19:53 -0700 (PDT) Message-ID: <46690316.10202@gmail.com> Date: Fri, 08 Jun 2007 09:19:50 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [RAM] [Fwd: I-D ACTION:draft-carpenter-idloc-map-cons-01.txt] References: <20070607154149.8056C86AED@mercury.lcs.mit.edu> In-Reply-To: <20070607154149.8056C86AED@mercury.lcs.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) 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 below... On 2007-06-07 17:41, Noel Chiappa wrote: > > From: Scott W Brim > > > - "Within its site, A must have an Identifier and Locator that match > > - 1:1 for the convenience of operational staff" > > > Do you really mean 1:1? There needs to be at least one Identifier > > known to operations staff which maps to a particular locator, but > > there can be more. > > I haven't read the full text of the latest version yet, but this (and I > don't know the whole context, maybe it's somehow less restrictive than it > sounds) caught my eye. > > If identifiers and locators have a 1:1 relationship, a variety of things > become impossible (such as doing widespread smale-scale multihoming using > identifer<->locator bindings, with multiple locators bound to a single > identifier). > > > In fact, making that restriction removes much of the value of having > separate "locator" and "identifier" namespaces. If A is 1:1 to B, then you > can use A all the time, and having B around offers you no value. > > The only exception to that observation would be if the binding can be > changed over time, while remaining restricted to 1:1 bindings. (So that > e.g. A could be bound to B at one point, and later A could be bound to C > instead.) That would at least support mobility. > > > Still, it's a very crippling restriction, and while it might have some > value in operational simplicity, one wonders if the cost in lost potential > functionality is not much higher than what it buys you. Actually it's plain wrong, in that in IPv6, the same interface can have multiple addresses anyway. I'll have to review the 01 text to be sure it's OK, but most of the problems were in the 00 text. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 08 03:22: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 1HwYnO-0005xI-2d; Fri, 08 Jun 2007 03:22:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYnL-0005tT-VQ for ram@iab.org; Fri, 08 Jun 2007 03:22:03 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwYnK-0003Vv-GO for ram@iab.org; Fri, 08 Jun 2007 03:22:03 -0400 Received: by ug-out-1314.google.com with SMTP id m2so948261uge for ; Fri, 08 Jun 2007 00:22:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=YQWnY2mEsC0dZLM76skph9N3SWnXvWKXZpjkXmt8zJehuGvvmO6SWV/L23H1I9dcGFqTz5Hxmy+vG1BhXnTi4TLbjXnJ2KIaq8XQ8aDkpg/Po/gKGgkPRQUKdRnPsdRQUAUpt0E8E7ikUR1NydaPgB85I5tIav05S/PUgCrQX50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=S6yR2cZjIJpjl8ncXLwdAMz85GURZPWNWVonTO93wQSECImgqxeiiA+88sNu+Xe+pkjm4ji7ftoPB5ok8OjIrMlEcNZoLa99sN63vNd3tGkCTcYiMzwqwnHIFYmuMstib2NrFfWHqJyHWHAvCHWnIahIILLqJiE7LCWqToj6Q+E= Received: by 10.82.182.1 with SMTP id e1mr4716191buf.1181287321735; Fri, 08 Jun 2007 00:22:01 -0700 (PDT) Received: from ?9.159.130.110? ( [195.212.29.163]) by mx.google.com with ESMTP id d23sm4814617nfh.2007.06.08.00.22.00 (version=SSLv3 cipher=RC4-MD5); Fri, 08 Jun 2007 00:22:01 -0700 (PDT) Message-ID: <46690396.5020003@gmail.com> Date: Fri, 08 Jun 2007 09:21:58 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: HeinerHummel@aol.com Subject: Re: [RAM] [Fwd: I-D ACTION:draft-carpenter-idloc-map-cons-01.txt] 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: 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 On 2007-06-07 18:17, HeinerHummel@aol.com wrote: > Maybe I don't understand the whole topic: Are we really after a loc/id-split > or are we after a "2 locators"-addressing scheme ? That's not the topic of a draft supposedly about mapping, but it's a good question. It's why I've asserted that LISP isn't really an id-loc split at all. We need some agreed terminology. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 08 10: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 1HwfCo-0002jI-FL; Fri, 08 Jun 2007 10:12:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwfCn-0002hw-MZ for ram@iab.org; Fri, 08 Jun 2007 10:12:45 -0400 Received: from eastrmmtao104.cox.net ([68.230.240.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwfBI-0002qr-UF for ram@iab.org; Fri, 08 Jun 2007 10:11:14 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070608141110.SJDX8179.eastrmmtao104.cox.net@eastrmimpo01.cox.net> for ; Fri, 8 Jun 2007 10:11:10 -0400 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id 92B91X00T0pnMhQ0000000; Fri, 08 Jun 2007 10:11:10 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <1441B660-CC5A-441D-8D72-724560E50008@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: RJ Atkinson Date: Fri, 8 Jun 2007 10:11:08 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [RAM] Crisper Terminology X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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-06-07 18:17, HeinerHummel at aol.com wrote: >> Maybe I don't understand the whole topic: Are we really after a >> loc/id-split or are we after a "2 locators"-addressing scheme ? Later, Brian Carpenter wrote: > That's not the topic of a draft supposedly about mapping, but it's > a good > question. It's why I've asserted that LISP isn't really an id-loc > split > at all. We need some agreed terminology. I'd agree with Brian that LISP is a dual-locator scheme, rather than an ID-Locator split. This isn't criticism of LISP, just an effort to have clear terminology so that discussion can be clear and focused. Yours, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 08 10:23: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 1HwfNN-0002pu-0S; Fri, 08 Jun 2007 10:23:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwfNL-0002pp-VK for ram@iab.org; Fri, 08 Jun 2007 10:23:39 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwfNK-0002vi-4o for ram@iab.org; Fri, 08 Jun 2007 10:23:39 -0400 Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 09 Jun 2007 08:50:08 +0530 X-IronPort-AV: i="4.16,400,1175452200"; d="scan'208"; a="81755132:sNHT52903806" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l58ENYIq028155; Fri, 8 Jun 2007 22:23:34 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l58ENSq2023213; Fri, 8 Jun 2007 14:23:33 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 22:23:27 +0800 Received: from [10.66.254.216] ([10.66.254.216]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 22:23:24 +0800 Message-ID: <46696627.7010407@employees.org> Date: Fri, 08 Jun 2007 10:22:31 -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.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] Crisper Terminology References: <1441B660-CC5A-441D-8D72-724560E50008@extremenetworks.com> In-Reply-To: <1441B660-CC5A-441D-8D72-724560E50008@extremenetworks.com> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2007 14:23:27.0095 (UTC) FILETIME=[9463D870:01C7A9D8] Authentication-Results: hkg-dkim-1; header.From=swb@employees.org; dkim=neutral 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 On 06/08/2007 10:11 AM, RJ Atkinson allegedly wrote: > I'd agree with Brian that LISP is a dual-locator scheme, rather than > an ID-Locator split. This isn't criticism of LISP, just an effort > to have clear terminology so that discussion can be clear and > focused. Some approaches have IP-layer identifiers that are in fact pure identifiers. Others like LISP use locally-significant locators as identifiers, when outside of their locator scope. The syntax is the same but the semantics are different [Noel: dessert vs appetizer]. I don't believe we need new taxonomy for ID and RLOC, just to be clear about how a name is being used at all times. We could use terminology for the different approaches -- Lixia and I are trying to work on that. Scott _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 08 10:31: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 1HwfUU-0005QW-4g; Fri, 08 Jun 2007 10:31:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwfUS-0005PS-HL for ram@iab.org; Fri, 08 Jun 2007 10:31:00 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwfUR-00053g-8X for ram@iab.org; Fri, 08 Jun 2007 10:31:00 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Jun 2007 16:30:59 +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 l58EUw2f027998; Fri, 8 Jun 2007 16:30:58 +0200 Received: from elear-mac.local (ams3-vpn-dhcp597.cisco.com [10.61.66.85]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l58EUrDR027839; Fri, 8 Jun 2007 14:30:54 GMT Message-ID: <4669681D.2060705@cisco.com> Date: Fri, 08 Jun 2007 15:30:53 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] Crisper Terminology References: <1441B660-CC5A-441D-8D72-724560E50008@extremenetworks.com> In-Reply-To: <1441B660-CC5A-441D-8D72-724560E50008@extremenetworks.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=331; t=1181313058; x=1182177058; 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]=20Crisper=20Terminology |Sender:=20; bh=GKCWxYG62OZh7HvhxWk+lEnwEt7ZbV1ZLM9OMlO8QrQ=; b=grkngpv0vHsTDa7TG48Co/wBVohLjOPgx7bdCjvxnKDvKuelsZTgqm6G1enzGjIRKzxmn4M4 +NXYLbbXUdZQUJDn4Z8Hz2TpS8zffeWzRc/TiIaTISensU6MqjSgXjLl; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 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 RJ Atkinson wrote: > I'd agree with Brian that LISP is a dual-locator scheme, > rather than an ID-Locator split. This isn't criticism > of LISP, just an effort to have clear terminology so > that discussion can be clear and focused. +1 on both counts. And perhaps that's why it can be implemented off the box. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 08 11:33: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 1HwgT8-0008V6-Nf; Fri, 08 Jun 2007 11:33:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwgT7-0008QT-FS for ram@iab.org; Fri, 08 Jun 2007 11:33:41 -0400 Received: from eastrmmtao104.cox.net ([68.230.240.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwgT6-00016L-5s for ram@iab.org; Fri, 08 Jun 2007 11:33:41 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070608153340.UMTB8179.eastrmmtao104.cox.net@eastrmimpo01.cox.net> for ; Fri, 8 Jun 2007 11:33:40 -0400 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id 93Zf1X0090pnMhQ0000000; Fri, 08 Jun 2007 11:33:39 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <46696627.7010407@employees.org> References: <1441B660-CC5A-441D-8D72-724560E50008@extremenetworks.com> <46696627.7010407@employees.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Crisper Terminology Date: Fri, 8 Jun 2007 11:33:37 -0400 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) 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 8 Jun 2007, at 10:22, Scott W Brim wrote: > Some approaches have IP-layer identifiers that are in fact pure > identifiers. Others like LISP use locally-significant locators as > identifiers, when outside of their locator scope. The syntax is the > same but the semantics are different [Noel: dessert vs appetizer]. If the semantics are different -- and I agree that they are -- then we ought to use a different term. Again, this is not criticising any idea, just seeking greater clarity in meaning during discussions. > I don't believe we need new taxonomy for ID and RLOC, just to be clear > about how a name is being used at all times. We could use terminology > for the different approaches -- Lixia and I are trying to work on > that. I think that semantic overloading is a lot of how we got here, so I do believe we need a taxonomy that uses different names for objects with different semantics. Yours, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 08 12:20: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 1HwhCJ-0002HA-Ke; Fri, 08 Jun 2007 12:20:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwhCI-00026i-KN for ram@iab.org; Fri, 08 Jun 2007 12:20:22 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwhCH-0003st-EI for ram@iab.org; Fri, 08 Jun 2007 12:20:22 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1266686AF0; Fri, 8 Jun 2007 12:20:21 -0400 (EDT) To: ram@iab.org, rja@extremenetworks.com Subject: Re: [RAM] Crisper Terminology Message-Id: <20070608162021.1266686AF0@mercury.lcs.mit.edu> Date: Fri, 8 Jun 2007 12:20:21 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 > I'd agree with Brian that LISP is a dual-locator scheme, rather than an > ID-Locator split. We've beaten this horse rather thoroughly in the past, so I won't belabour it at length now, but I disagree. Very briefly, the transport layer needs a name to distinguish the entity at the other end with which it is communicating. That name is what we are calling the "identifier" (for me, that's short for "endpoint identifier", OMMV). Thus, any bit-string/name which serves this purpose of naming the transport-layer entity at the other end is, *by definition*, an "identifier". It may *also* have some locational semantics (as the one of the two LISP namespaces which is an identifier does), but it is *not* - nay, *cannot* be - a pure locator. > This isn't criticism of LISP, just an effort to have clear terminology > so that discussion can be clear and focused. Understood. However, as I hope I make clear above, thinking that this name is *not* an identifier is, to me, a source of potential confusion. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 08 12:27: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 1HwhJF-0007y6-Vs; Fri, 08 Jun 2007 12:27:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwhJD-0007uL-St for ram@iab.org; Fri, 08 Jun 2007 12:27:31 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwhJC-0006F7-N9 for ram@iab.org; Fri, 08 Jun 2007 12:27:31 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7046286AF0; Fri, 8 Jun 2007 12:27:30 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Crisper Terminology Message-Id: <20070608162730.7046286AF0@mercury.lcs.mit.edu> Date: Fri, 8 Jun 2007 12:27:30 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: Scott W Brim > Some approaches have IP-layer identifiers that are in fact pure > identifiers. Others like LISP use locally-significant locators as > identifiers, when outside of their locator scope. Just to clarify something (you probably meant this, but the words don't quite say this), it's always an identifier, wherever it is in the network (i.e. either inside or outside its locator scope). I think there is general agreement/understanding that it's only meaningful/useful as a locator inside its locator scope. (Which one would think would naturally lead one to the question "What is it when it's outside that scope, since it's not a locator out there", but I digress...) Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 08 13:26: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 1HwiDk-0007KF-Vq; Fri, 08 Jun 2007 13:25:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwiDj-0007K7-Do for ram@iab.org; Fri, 08 Jun 2007 13:25:55 -0400 Received: from eastrmmtao102.cox.net ([68.230.240.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwiDj-0006KM-4q for ram@iab.org; Fri, 08 Jun 2007 13:25:55 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao102.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070608172556.BLWP8985.eastrmmtao102.cox.net@eastrmimpo01.cox.net> for ; Fri, 8 Jun 2007 13:25:56 -0400 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id 95Ru1X00K0pnMhQ0000000; Fri, 08 Jun 2007 13:25:54 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20070608162021.1266686AF0@mercury.lcs.mit.edu> References: <20070608162021.1266686AF0@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1061608D-5E5D-45E9-965C-9E66B4C41E95@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Crisper Terminology Date: Fri, 8 Jun 2007 13:25:53 -0400 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Jun 2007, at 12:20, Noel Chiappa wrote: >> From: RJ Atkinson > >> I'd agree with Brian that LISP is a dual-locator scheme, rather >> than an >> ID-Locator split. > > We've beaten this horse rather thoroughly in the past, > so I won't belabour it at length now, but I disagree. > > Very briefly, the transport layer needs a name to distinguish the > entity at the other end with which it is communicating. That name > is what we are calling the "identifier" (for me, that's short for > "endpoint identifier", OMMV). Thus, any bit-string/name which serves > this purpose of naming the transport-layer entity at the other end is, > *by definition*, an "identifier". It may *also* have some locational > semantics (as the one of the two LISP namespaces which is an > identifier does), but it is *not* - nay, *cannot* be - a pure > locator. There is a perfectly good a name for objects with both identification and location semantics. This community generally calls them addresses. For example, the existing TCP implementations use an IP address as the endpoint name for TCP purposes. >> This isn't criticism of LISP, just an effort to have clear >> terminology >> so that discussion can be clear and focused. > > Understood. However, as I hope I make clear above, thinking that > this name is *not* an identifier is, to me, a source of potential > confusion. This is the crux of the disagreement. Most of this community uses "Identifier" to mean a pure Identifier -- with no locational semantics -- and has had that meaning for about a decade now. The object with mixed semantics has been called an "Address" in this community for decades. People understand that an address has both locational semantics and identification semantics. The difference does matter for clarity of discussion here, because the semantics of an Identifier and of an Address differ -- and this discussion needs to remain architectural (where semantics do matter) if it is going to be productive. My guess is that this community is going to end up preferring to retain the address and go with LISP, but the best/fastest way to figure out the issues is to have clear, crisp terminology. Cheers, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 08 15:15: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 1HwjvH-0000yK-Ly; Fri, 08 Jun 2007 15:14:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjvF-0000x7-N4 for ram@iab.org; Fri, 08 Jun 2007 15:14:57 -0400 Received: from imo-d03.mx.aol.com ([205.188.157.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwjvF-00068A-5y for ram@iab.org; Fri, 08 Jun 2007 15:14:57 -0400 Received: from HeinerHummel@aol.com by imo-d03.mx.aol.com (mail_out_v38_r9.2.) id n.ceb.11fdf5c9 (32913) for ; Fri, 8 Jun 2007 15:14:52 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Fri, 8 Jun 2007 15:14:51 EDT Subject: Re: [RAM] Crisper Terminology To: ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5014 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 X-BeenThere: ram@iab.org X-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="===============1117679693==" Errors-To: ram-bounces@iab.org --===============1117679693== Content-Type: multipart/alternative; boundary="-----------------------------1181330091" -------------------------------1181330091 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 We are dealing here with some information and the ways we are using it give=20= =20 it different meanings. Is the used information sufficient or does it need some extension? Are the =20 ways we use it still appropriate or do our handling mechanisms cause probl= ems=20 and should therefore better be changed or replaced ? =20 Obviously, new developments and applications as well as the internet growth=20= =20 itself demand for changes and improvements. =20 Two natures of the information are in stake: location information and =20 identification information. First we should know what shall be accomplished, then we can see what is to= =20 be changed. =20 Routing is a big issue, but as far as I can observe, all just stick to the=20 traditional mechanisms and prefer a fundamental change rather be postponed.= TE=20 is accused to be part of the problem. But isn't in this case the mechanism=20 itself a subject for chapter 11 ? =20 Identification is an urgent problem, too (e.g.we are running out of=20 IPv4-addresses). Brian wrote: "is more so" meaning IPv6 is just more of IPv4. Very true. =20 Correct me if I am wrong:the IPv6 address space does not INCLUDE the IPv4 a= ddress=20 space. If so, is that good or rather bad ? intended or unintended ? Why =20 isn't there an address family Identifier (AFI) ? One for IPv4, one for IPv6=20= ? Or:=20 one for roaming users rather than static users? One for E.164 (instead of =20 DNS mapping a la enum) ? Etc. etc. =20 And given such multiple address families processing types like unicast, =20 anycast, multicast, mp2p, mp2mp becomes really orthogonal to it, i.e. needs to be differentiated by =20 operational flags rather than address subranges !=20 =20 Both locating and identification have their special aspects by themselves.= =20 Both shall be handled accordingly. =20 The current discussion rather shows that the split itself is the real goal,=20= =20 the true objective - which is not. =20 Heiner =20 =20 =20 In einer eMail vom 08.06.2007 19:26:29 Westeurop=E4ische Normalzeit schreibt= =20 rja@extremenetworks.com: On 8 Jun 2007, at 12:20, Noel Chiappa wrote: >> From: RJ Atkinson > >> I'd agree with Brian that LISP is a dual-locator scheme, rather =20 >> than an >> ID-Locator split. > > We've beaten this horse rather thoroughly in the past, > so I won't belabour it at length now, but I disagree. > > Very briefly, the transport layer needs a name to distinguish the > entity at the other end with which it is communicating. That name > is what we are calling the "identifier" (for me, that's short for > "endpoint identifier", OMMV). Thus, any bit-string/name which serves > this purpose of naming the transport-layer entity at the other end is, > *by definition*, an "identifier". It may *also* have some locational > semantics (as the one of the two LISP namespaces which is an > identifier does), but it is *not* - nay, *cannot* be - a pure > locator. There is a perfectly good a name for objects with both identification and location semantics. This community generally calls them addresses. For example, the existing TCP implementations use an IP address as the endpoint name for TCP purposes. >> This isn't criticism of LISP, just an effort to have clear =20 >> terminology >> so that discussion can be clear and focused. > > Understood. However, as I hope I make clear above, thinking that > this name is *not* an identifier is, to me, a source of potential > confusion. This is the crux of the disagreement. Most of this community uses "Identifier" to mean a pure Identifier -- with no locational semantics -- and has had that meaning for about a decade now. The object with mixed semantics has been called an "Address" in this community for decades. People understand that an address has both locational semantics and identification semantics. The difference does matter for clarity of discussion here, because the semantics of an Identifier and of an Address differ -- and this discussion needs to remain architectural (where semantics do matter) if it is going to be productive. My guess is that this community is going to end up preferring to retain the address and go with LISP, but the best/fastest way to figure out the issues is to have clear, crisp terminology. Cheers, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram =20 -------------------------------1181330091 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
We are dealing here with some information and the ways we are using it=20= give=20 it different meanings.
Is the used information sufficient or does it need some extension? Are=20= the=20 ways we use it still appropriate or do our handling mechanisms  cause=20 problems and should therefore better be changed or replaced ?
 
Obviously, new developments and applications as well as the internet gr= owth=20 itself demand for changes and improvements.
 
Two natures of the information are in stake: location information and=20 identification information.
First we should know what shall be accomplished, then we can see w= hat=20 is to be changed.
 
Routing is a big issue, but as far as I can observe, all just stic= k to=20 the traditional mechanisms and prefer a fundamental change rather be=20 postponed. TE is accused to be part of the problem. But isn't in this case t= he=20 mechanism itself a subject for chapter 11 ?
 
Identification is an urgent problem, too (e.g.we are running out=20 of IPv4-addresses).
Brian wrote: "is more so" meaning IPv6 is just more of IPv4. Very true.= =20 Correct me if I am wrong:the IPv6 address space does not INCLUDE the IPv4=20 address space. If so, is that good or rather bad ? intended or unintended ?=20= Why=20 isn't there an address family Identifier (AFI) ? One for IPv4, one for IPv6=20= ?=20 Or: one for roaming users rather than static users? One for E.164 (instead o= f=20 DNS mapping a la enum) ? Etc. etc.
 
And given such multiple address families processing types like unicast,= =20 anycast, multicast, mp2p, mp2mp
becomes really orthogonal to it, i.e. needs to be differentiated by=20 operational flags rather than address subranges !
 
Both locating  and identification have their special aspects=20= by=20 themselves. Both shall be handled accordingly.
 
The current discussion rather shows that the split itself is the real g= oal,=20 the true objective - which is not.
 
Heiner
 
 
 
In einer eMail vom 08.06.2007 19:26:29 Westeurop=E4ische Normalzeit sch= reibt=20 rja@extremenetworks.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On =20 8 Jun 2007, at 12:20, Noel Chiappa wrote:
>> From: RJ Atkinson=20 <rja@extremenetworks.com>
>
>> I'd agree with Brian t= hat=20 LISP is a dual-locator scheme, rather 
>> than an
>&g= t;=20 ID-Locator split.
>
> We've beaten this horse rather thoroughl= y in=20 the past,
> so I won't belabour it at length now, but I=20 disagree.
>
> Very briefly, the transport layer needs a name t= o=20 distinguish the
> entity at the other end with which it is=20 communicating. That name
> is what we are calling the "identifier" (= for=20 me, that's short for
> "endpoint identifier", OMMV). Thus, any=20 bit-string/name which serves
> this purpose of naming the=20 transport-layer entity at the other end is,
> *by definition*, an=20 "identifier".  It may *also* have some locational
> semantics (= as=20 the one of the two LISP namespaces which is an
> identifier does), b= ut=20 it is *not* - nay, *cannot* be - a pure
> locator.

There is a= =20 perfectly good a name for objects with both identification
and location= =20 semantics.  This community generally calls them addresses.
For=20 example, the existing TCP implementations use an IP address
as the endp= oint=20 name for TCP purposes.

>> This isn't criticism of LISP, just=20= an=20 effort to have clear 
>> terminology
>> so that=20 discussion can be clear and focused.
>
> Understood. However,=20= as I=20 hope I make clear above, thinking that
> this name is *not* an=20 identifier is, to me, a source of potential
> confusion.

This= is=20 the crux of the disagreement.  Most of this community=20 uses
"Identifier" to mean a pure Identifier -- with no locational=20 semantics
-- and has had that meaning for about a decade now.

Th= e=20 object with mixed semantics has been called an "Address" in this
commun= ity=20 for decades.  People understand that an address has both
locationa= l=20 semantics and identification semantics.

The difference does matter=20= for=20 clarity of discussion here,
because the semantics of an Identifier and=20= of=20 an Address
differ -- and this discussion needs to remain=20 architectural
(where semantics do matter) if it is going to be=20 productive.

My guess is that this community is going to end up=20 preferring
to retain the address and go with LISP, but the=20 best/fastest
way to figure out the issues is to have clear, crisp=20 terminology.

Cheers,

Ran


________________________= _______________________
RAM=20 mailing=20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 -------------------------------1181330091-- --===============1117679693== 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 --===============1117679693==-- From ram-bounces@iab.org Fri Jun 08 15:46: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 1HwkPW-0004f4-7P; Fri, 08 Jun 2007 15:46:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwkPV-0004Z2-3x for ram@iab.org; Fri, 08 Jun 2007 15:46:13 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwkPT-00064N-Sl for ram@iab.org; Fri, 08 Jun 2007 15:46:13 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Jun 2007 15:46:12 -0400 X-IronPort-AV: i="4.16,400,1175486400"; d="scan'208"; a="62323677:sNHT44370832" 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 l58JkB8Q008106; Fri, 8 Jun 2007 15:46:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l58Jju5l010788; Fri, 8 Jun 2007 19:46:07 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); Fri, 8 Jun 2007 15:45:59 -0400 Received: from [10.86.242.74] ([10.86.242.74]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 15:45:58 -0400 Message-ID: <4669B1C4.5030800@employees.org> Date: Fri, 08 Jun 2007 15:45:08 -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.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] Crisper Terminology References: <1441B660-CC5A-441D-8D72-724560E50008@extremenetworks.com> <46696627.7010407@employees.org> In-Reply-To: X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2007 19:45:59.0068 (UTC) FILETIME=[A31095C0:01C7AA05] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral 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 On 06/08/2007 11:33 AM, RJ Atkinson allegedly wrote: > > On 8 Jun 2007, at 10:22, Scott W Brim wrote: >> Some approaches have IP-layer identifiers that are in fact pure >> identifiers. Others like LISP use locally-significant locators as >> identifiers, when outside of their locator scope. The syntax is the >> same but the semantics are different [Noel: dessert vs appetizer]. > > If the semantics are different -- and I agree that they are -- > then we ought to use a different term. But we do: name (the generic term), locator (RLOC and all its other names) and identifier. In LISP, for example, between the source and the ITR an IP address is an RLOC. When it hits an ITR and a lookup for an ETR is done, the IP address is used as an end system identifier. Is there an issue? _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jun 09 02:43: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 1Hwuee-0008VN-BV; Sat, 09 Jun 2007 02:42:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwueb-0008Nd-Fc for ram@iab.org; Sat, 09 Jun 2007 02:42:30 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwueZ-0004ED-6p for ram@iab.org; Sat, 09 Jun 2007 02:42:28 -0400 Received: by ug-out-1314.google.com with SMTP id m2so1197305uge for ; Fri, 08 Jun 2007 23:42:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=QZRDXwVLWfVdixZr8MhcCac928E0dFWc5GBV6tlRs0LxLU4FFlAtv6tm1sYeeNcWLkIGjtnDRM/ogOQgNQby3Q9Gk08VaV6bLDGfH+mdcE1S0ZTUkHF5Fk9wZ3TC+OPxaeXvsX584majkUO7fmc6firecjSjaLwgWfnlZ4xbeVg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ovZz0luyctlYpT1oQ2UTGOcRar2+XODPJB/eTylsk5nYKFzvIcStF/1w0Fk/L/BEELNmT1AqJzCuJTcvOUazuIs8refBQifkqNTPGpQGkyfsrdZI2yemQ5tnx2MkUCDKvgkrXKR0BCa78l/TD3CaegqoEIpEv908+VRc8LRuOPk= Received: by 10.66.249.8 with SMTP id w8mr2528311ugh.1181371346349; Fri, 08 Jun 2007 23:42:26 -0700 (PDT) Received: from ?192.168.1.101? ( [213.103.155.32]) by mx.google.com with ESMTP id w40sm2353521ugc.2007.06.08.23.42.23 (version=SSLv3 cipher=RC4-MD5); Fri, 08 Jun 2007 23:42:23 -0700 (PDT) Message-ID: <466A4BCE.4010208@gmail.com> Date: Sat, 09 Jun 2007 08:42:22 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] Crisper Terminology References: <20070608162021.1266686AF0@mercury.lcs.mit.edu> <1061608D-5E5D-45E9-965C-9E66B4C41E95@extremenetworks.com> In-Reply-To: <1061608D-5E5D-45E9-965C-9E66B4C41E95@extremenetworks.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 2007-06-08 19:25, RJ Atkinson wrote: ... > There is a perfectly good a name for objects with both identification > and location semantics. This community generally calls them addresses. I'd be tempted to agree with that, but I just had occasion to review draft-ietf-ccamp-gmpls-addressing-07.txt, and found my head spinning rapidly on exactly this question. > For example, the existing TCP implementations use an IP address > as the endpoint name for TCP purposes. Well, if we use OSI formalism, we'd have to say that the transport address is the network address concatenated with the port number. There was a fairly clear model for layered endpoint addressing in OSI, and it still a valid thinking aid IMHO. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jun 09 12:19: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 1Hx3eC-0004Eu-DR; Sat, 09 Jun 2007 12:18:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx3eA-00045M-3N for ram@iab.org; Sat, 09 Jun 2007 12:18:38 -0400 Received: from xmail06.myhosting.com ([168.144.250.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hx3e8-0004N3-RJ for ram@iab.org; Sat, 09 Jun 2007 12:18:38 -0400 Received: (qmail 24039 invoked from network); 9 Jun 2007 16:18:36 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Jun 2007 16:18:35 -0000 Message-ID: <466AD2DA.3050700@cisco.com> Date: Sat, 09 Jun 2007 12:18:34 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] Crisper Terminology References: <20070608162021.1266686AF0@mercury.lcs.mit.edu> <1061608D-5E5D-45E9-965C-9E66B4C41E95@extremenetworks.com> In-Reply-To: <1061608D-5E5D-45E9-965C-9E66B4C41E95@extremenetworks.com> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > My guess is that this community is going to end up preferring > to retain the address and go with LISP, but the best/fastest > way to figure out the issues is to have clear, crisp terminology. There are actually two parts to this: 1. The sort of split LISP uses. 2. The protocols used to provide the magic mapping between the locator and the ID. So far, the split appears to be "assumed," and the harder points about this split have been not discussed at all. The discussion has centered around the mapping protocols, with mobility being taken off the table as being a problem to solve. IMHO, there are two dangerous decisions here, one not to discuss the implications of a loc/id split, and the other to take mobility off the table as a problem to be solved. But, I've made those points in the past, to no avail, so there's no reason to belabor them here again. :-) 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 iD8DBQFGatLZER27sUhU9OQRApY1AJ0bbMYwzidicT/9dgTPVEN+TKjrzACg0sJV bsThCiJFrNMcVx7sy3fR4vM= =kuQS -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jun 09 16: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 1Hx7pI-0004p3-D9; Sat, 09 Jun 2007 16:46:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx7pG-0004ox-KR for ram@iab.org; Sat, 09 Jun 2007 16:46:22 -0400 Received: from imo-m25.mx.aol.com ([64.12.137.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hx7pG-0000jK-5e for ram@iab.org; Sat, 09 Jun 2007 16:46:22 -0400 Received: from HeinerHummel@aol.com by imo-m25.mx.aol.com (mail_out_v38_r9.2.) id c.cb2.13164642 (41809); Sat, 9 Jun 2007 16:45:55 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Sat, 9 Jun 2007 16:45:55 EDT Subject: Re: [RAM] Crisper Terminology To: riw@cisco.com, rja@extremenetworks.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5014 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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="===============0430035404==" Errors-To: ram-bounces@iab.org --===============0430035404== Content-Type: multipart/alternative; boundary="-----------------------------1181421955" -------------------------------1181421955 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 09.06.2007 18:19:11 Westeurop=E4ische Normalzeit schreibt= =20 riw@cisco.com: So far, the split appears to be "assumed," and the harder points about this split have been not discussed at all. The discussion has centered around the mapping protocols, with mobility being taken off the table as being a problem to solve. IMHO, there are two dangerous decisions here, one not to discuss the implications of a loc/id split, and the other to take mobility off the table as a problem to be solved. The split appears to be "assumed". My similar impression: the split appears= =20 to be a goal by itself. =20 ...mobility being taken off the table :=20 My hope is that such services increase the pressure for accepting new=20 solutions. Not of the kind "wash me but don't make me wet". Not of the kind= where=20 backward-compatibility is the first thing to be considered (in the end even the most revolutionary approach will need operational=20 mechanisms,too, that can be re-used). =20 There are a lot of "identifier"-issues ( I addressed some of them lately). =20 And there are still the routing issues. By going for a solution that eliminates the routing problems addressed by =20 the IAB raw report, mobility services would have a new and brighter base fo= r=20 sure. =20 Heiner =20 =20 =20 =20 =20 =20 -------------------------------1181421955 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 09.06.2007 18:19:11 Westeurop=E4ische Normalzeit sch= reibt=20 riw@cisco.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>So far,=20 the split appears to be "assumed," and the harder points about
this spl= it=20 have been not discussed at all. The discussion has centered
around the=20 mapping protocols, with mobility being taken off the table as
being a=20 problem to solve.

IMHO, there are two dangerous decisions here, one= not=20 to discuss the
implications of a loc/id split, and the other to take=20 mobility off the
table as a problem to be=20 solved.

 
The split appears to be "assumed". My similar impression: the=20 split appears to be a goal by itself.
 
...mobility being taken off the table :
My hope is that such services increase the pressure for accepting=20  new solutions. Not of the kind "wash me but don't make me wet". Not of= the=20 kind where backward-compatibility is the first thing to be considered
(in the end even the most revolutionary approach will need&nb= sp;=20 operational mechanisms,too, that can be re-used).
 
There are a lot of "identifier"-issues ( I addressed some of them latel= y).=20 And there are still the routing issues.
By going for a solution that eliminates the routing problems addressed=20= by=20 the IAB raw report, mobility services would have a new and brighter bas= e=20 for sure.
 
Heiner
 
 
 
 
 
-------------------------------1181421955-- --===============0430035404== 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 --===============0430035404==-- From ram-bounces@iab.org Sat Jun 09 19:10: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 1HxA4B-00016F-2d; Sat, 09 Jun 2007 19:09:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxA49-00016A-HT for ram@iab.org; Sat, 09 Jun 2007 19:09:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxA48-0004zF-TQ for ram@iab.org; Sat, 09 Jun 2007 19:09:53 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Jun 2007 16:09:52 -0700 X-IronPort-AV: i="4.16,403,1175497200"; d="scan'208,217"; a="161851738:sNHT75829428" 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 l59N9q9d005624; Sat, 9 Jun 2007 16:09:52 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l59N9gaI026909; Sat, 9 Jun 2007 23:09:42 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); Sat, 9 Jun 2007 16:09:42 -0700 Received: from [192.168.0.100] ([10.21.83.4]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Jun 2007 16:09:41 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Tony Li Subject: Re: [RAM] Crisper Terminology Date: Sat, 9 Jun 2007 16:09:40 -0700 To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Jun 2007 23:09:41.0808 (UTC) FILETIME=[42CC7300:01C7AAEB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5232; t=1181430592; x=1182294592; 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]=20Crisper=20Terminology |Sender:=20; bh=yohmY36cd3hEA6tNL88IHTnyhGOsP62kzlNQ4lyxr08=; b=bY+6ZIJHfJeqvTBknkzzN5hYyO2L6B8vBtciZbn0YxGRrgQC/hIFw187tLTj1KT06n3bV3My 1XlVA9qO4LRSNeZpYd5shqO7cRu13ttdgDSDROtdEREjOtPfUWZMlwYLlWjx1/h7VNksBZVG65 a2DMU87PVLfqSYumurQRdMVi4=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: rja@extremenetworks.com, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0689585041==" Errors-To: ram-bounces@iab.org --===============0689585041== Content-Type: multipart/alternative; boundary=Apple-Mail-16--887565728 --Apple-Mail-16--887565728 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed I can only speak for the RRG: the mobility implications of the Loc/ID =20= split are still very much on the table. Tony On Jun 9, 2007, at 1:45 PM, HeinerHummel@aol.com wrote: > In einer eMail vom 09.06.2007 18:19:11 Westeurop=E4ische Normalzeit =20= > schreibt riw@cisco.com: > So far, the split appears to be "assumed," and the harder points about > this split have been not discussed at all. The discussion has centered > around the mapping protocols, with mobility being taken off the =20 > table as > being a problem to solve. > > IMHO, there are two dangerous decisions here, one not to discuss the > implications of a loc/id split, and the other to take mobility off the > table as a problem to be solved. > > > The split appears to be "assumed". My similar impression: the split =20= > appears to be a goal by itself. > > ...mobility being taken off the table : > My hope is that such services increase the pressure for accepting =20 > new solutions. Not of the kind "wash me but don't make me wet". Not =20= > of the kind where backward-compatibility is the first thing to be =20 > considered > (in the end even the most revolutionary approach will need =20 > operational mechanisms,too, that can be re-used). > > There are a lot of "identifier"-issues ( I addressed some of them =20 > lately). And there are still the routing issues. > By going for a solution that eliminates the routing problems =20 > addressed by the IAB raw report, mobility services would have a new =20= > and brighter base for sure. > > Heiner > > > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram --Apple-Mail-16--887565728 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

I can only speak for the = RRG: the mobility implications of the Loc/ID split are still very much = on the table.=A0=A0

Tony


On Jun 9, 2007, at = 1:45 PM, HeinerHummel@aol.com = wrote:

In einer eMail vom 09.06.2007 18:19:11 = Westeurop=E4ische Normalzeit schreibt riw@cisco.com:
So far, the split appears to be = "assumed," and the harder points about
this split have been not = discussed at all. The discussion has centered
around the mapping = protocols, with mobility being taken off the table as
being a = problem to solve.

IMHO, there are two dangerous decisions here, = one not to discuss the
implications of a loc/id split, and the = other to take mobility off the
table as a problem to be = solved.

=A0
=
The split appears to be "assumed". My similar impression: the = split=A0appears to be=A0a goal by itself.
=A0
=
...mobility being taken off the table :
My hope is that = such services increase the pressure for=A0accepting =A0new solutions. = Not of the kind "wash me but don't make me wet". Not of the kind where = backward-compatibility is the first thing to be considered
=
(in the end=A0even the most revolutionary approach=A0will need=A0 = operational mechanisms,too, that can be re-used).
=A0
=
There are a lot of "identifier"-issues ( I addressed some of them = lately). And there are still the routing issues.
By going for = a solution that eliminates the routing problems addressed by the IAB raw = report, mobility services would have a new and=A0brighter base for = sure.
=A0
Heiner
=A0
=A0
=
=A0
=A0
=A0
RAM mailing list

= --Apple-Mail-16--887565728-- --===============0689585041== 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 --===============0689585041==-- From ram-bounces@iab.org Sun Jun 10 03:08: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 1HxHVt-0006VP-0x; Sun, 10 Jun 2007 03:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxHVs-0006VG-AM for ram@iab.org; Sun, 10 Jun 2007 03:07:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxHVr-0005eD-2N for ram@iab.org; Sun, 10 Jun 2007 03:07:00 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Jun 2007 03:06:52 -0400 X-IronPort-AV: i="4.16,405,1175486400"; d="scan'208"; a="123226058:sNHT43764346" 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 l5A76qvk001720; Sun, 10 Jun 2007 03:06:52 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5A76k5f007577; Sun, 10 Jun 2007 07:06:50 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Jun 2007 03:06:46 -0400 Received: from [192.168.0.3] ([10.82.242.47]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Jun 2007 03:06:45 -0400 In-Reply-To: <4669B1C4.5030800@employees.org> References: <1441B660-CC5A-441D-8D72-724560E50008@extremenetworks.com> <46696627.7010407@employees.org> <4669B1C4.5030800@employees.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <39F1C936-79C8-4A3F-86EF-70504201D007@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Crisper Terminology Date: Sun, 10 Jun 2007 00:06:49 -0700 To: Scott W Brim X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Jun 2007 07:06:45.0850 (UTC) FILETIME=[E80EA3A0:01C7AB2D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=691; t=1181459212; x=1182323212; c=relaxed/simple; s=rtpdkim2001; 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]=20Crisper=20Terminology |Sender:=20 |To:=20Scott=20W=20Brim=20; bh=oprmg3/tgpiPRWVKfETPk6fVuJtDr4wBdIfFN9wT/QM=; b=Ae9gG9HlPZ8drLiodsf2Iadxd83iNSjCHpw9YjGRdLmqAu0xdnYtU7aYCIda67cDyat3nZJL ewLocmkvm9DEXhhkFStlEOHa+BQZDXGo8LFCK2LeoiQCB+rYVL1lBuq0; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 we do: name (the generic term), locator (RLOC and all its other > names) and identifier. In LISP, for example, between the source and > the ITR an IP address is an RLOC. When it hits an ITR and a lookup > for an ETR is done, the IP address is used as an end system > identifier. Is there an issue? Scoot, you are right with respect to functionality abut not semantics. An RLOC is the output, or what you get back, when you do an EID lookup. So RLOCs are really locators "in the global routing space". Between a source and an ITR, the addresses which are used are "scoped- routeable EIDs". Ditto on the destination site side from ETR to destination. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jun 10 03:11: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 1HxHZ3-0001eg-4a; Sun, 10 Jun 2007 03:10:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxHZ2-0001eZ-0J for ram@iab.org; Sun, 10 Jun 2007 03:10:16 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxHZ0-0006s1-PG for ram@iab.org; Sun, 10 Jun 2007 03:10:15 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Jun 2007 03:10:14 -0400 X-IronPort-AV: i="4.16,405,1175486400"; d="scan'208"; a="62381199:sNHT46968866" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5A7AETB002252; Sun, 10 Jun 2007 03:10:14 -0400 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 l5A7AEBe026139; Sun, 10 Jun 2007 07:10:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Jun 2007 03:10:13 -0400 Received: from [192.168.0.3] ([10.82.242.47]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Jun 2007 03:10:13 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Crisper Terminology Date: Sun, 10 Jun 2007 00:10:16 -0700 To: Tony Li X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Jun 2007 07:10:13.0333 (UTC) FILETIME=[63BA0850:01C7AB2E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=163; t=1181459414; x=1182323414; c=relaxed/simple; s=rtpdkim2001; 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]=20Crisper=20Terminology |Sender:=20 |To:=20Tony=20Li=20; bh=PoVY1KbzWkWXQjZgsqB4ghDQ70JVjlvkkHr05m53oyU=; b=PnjxmGjXZWE16pu/xlf/Yt6N+C1X+qGLI4uXeJSgr+gmjOTzaw70ZFDi/+O5jGwen6pgOjHH WB3cLTC9N4IDdHkzldbEddpvH55M0urMraZ2OTGHKkycytleKCorYDtF; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: HeinerHummel@aol.com, rja@extremenetworks.com, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > I can only speak for the RRG: the mobility implications of the Loc/ > ID split are still very much on the table. And ditto for the LISP designers. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jun 10 09:42: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 1HxNed-0007jv-M7; Sun, 10 Jun 2007 09:40:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxNeb-0007iW-3D for ram@iab.org; Sun, 10 Jun 2007 09:40:25 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxNeZ-0007CJ-Qe for ram@iab.org; Sun, 10 Jun 2007 09:40:25 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 322B619868B; Sun, 10 Jun 2007 16:40:22 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B204F19868A; Sun, 10 Jun 2007 16:40:12 +0300 (EEST) Message-ID: <466BFF2B.9060509@piuha.net> Date: Sun, 10 Jun 2007 16:39:55 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [RAM] Crisper Terminology References: <20070608162021.1266686AF0@mercury.lcs.mit.edu> <1061608D-5E5D-45E9-965C-9E66B4C41E95@extremenetworks.com> <466A4BCE.4010208@gmail.com> In-Reply-To: <466A4BCE.4010208@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Brian, > On 2007-06-08 19:25, RJ Atkinson wrote: > ... >> There is a perfectly good a name for objects with both identification >> and location semantics. This community generally calls them addresses. > > I'd be tempted to agree with that, but I just had occasion to > review draft-ietf-ccamp-gmpls-addressing-07.txt, and found my head > spinning rapidly on exactly this question. I actually do agree with Ran on this. (My head also started to spin on the same document that you mentioned, but I take it as an issue in the document, not in the terminology above...) Anyway, part of what complicates the terminology discussion is that some of the proposals employ addresses whose locator semantics are partial, e.g., usable as locators only on the edge, not in the core. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jun 10 12:00: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 1HxPoq-0000Pu-6S; Sun, 10 Jun 2007 11:59:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxPoo-0000Pp-Te for ram@iab.org; Sun, 10 Jun 2007 11:59:06 -0400 Received: from eastrmmtao103.cox.net ([68.230.240.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxPoo-0006UY-Hv for ram@iab.org; Sun, 10 Jun 2007 11:59:06 -0400 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070610155907.RZNJ8543.eastrmmtao103.cox.net@eastrmimpo02.cox.net> for ; Sun, 10 Jun 2007 11:59:07 -0400 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id 9rz51X00K0pnMhQ0000000; Sun, 10 Jun 2007 11:59:05 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <776D3684-8C59-459F-86AC-EE7D05A8855A@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: RJ Atkinson Date: Sun, 10 Jun 2007 11:59:06 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 1.6 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [RAM] (no subject) X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Heiner Hummel wrote: > Routing is a big issue, but as far as I can observe, all just stick > to the traditional mechanisms and prefer a fundamental change rather > be postponed. TE is accused to be part of the problem. But isn't > in this case the mechanism itself a subject for chapter 11 ? As near as I can tell, LISP changes how routing works. Certainly several large ISP staffers believe that some variants of LISP can alleviate their current concerns about scalability of inter-domain routing (and affordability of backbone routers). > Identification is an urgent problem, too (e.g.we are running out > of IPv4-addresses). Brian wrote: "is more so" meaning IPv6 is just > more of IPv4. Very true. We have lots of identifiers at hand, however, so I don't know that this is as big an issue as routing. For example, there are IEEE 802/1394 MAC addresses, which are widely available on end systems today and are in no danger of running out soon. To provide another example, fully-qualified domain names are widely available today and are also in no danger of running out soon. > Correct me if I am wrong: the IPv6 address space > does not INCLUDE the IPv4 address space. Not correct. There is a special prefix in IPv6 that says the low-order 32 bits are an IPv4 address. [RFC-4291, Section 2.5.5.2, Page 10-11] > One for E.164 (instead of DNS mapping a la enum) ? Etc. etc. I believe that it might also be possible to algorithmically place an E.164 into an NSAP and then into an IPv6 address using the special prefix that means an NSAP is in the low-order bits of the IPv6 address. It isn't clear to me whether this is explicitly documented at present. > The current discussion rather shows that the split itself is the > real goal, the true objective - which is not. I do not believe the split itself is the goal here. The current discussion has not indicated to me that the split is the goal; to the contrary, several of us have indicated that a split is not necessarily required. Solving certain operational issues is the goal. And the LISP proposal doesn't really split the Identifiers from the Locators, instead having various objects with mixed semantics (i.e. addresses), so that is a specific example of a current proposal without a clear split between pure Locators and pure Identifiers. Yours, Ran rja@extremenetworks.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jun 10 12:13: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 1HxQ1d-0007wA-8T; Sun, 10 Jun 2007 12:12:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxQ1b-0007vt-Os for ram@iab.org; Sun, 10 Jun 2007 12:12:19 -0400 Received: from eastrmmtao104.cox.net ([68.230.240.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxQ1b-00012y-7I for ram@iab.org; Sun, 10 Jun 2007 12:12:19 -0400 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070610161218.NABS8179.eastrmmtao104.cox.net@eastrmimpo02.cox.net> for ; Sun, 10 Jun 2007 12:12:18 -0400 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id 9sCJ1X0060pnMhQ0000000; Sun, 10 Jun 2007 12:12:18 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <9027C973-70C4-437A-9182-986063D7C7A8@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Sun, 10 Jun 2007 12:12:18 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [RAM] some draft proposed definitions X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here is a draft proposal for terminology, with the goal being greater clarity of communication. This is a starting point, not an all-inclusive list. Yours, Ran Identifier: An object that is used only for identification, never for forwarding packets or determining location. ID: Abbreviation for Identifier. Locator: An object that is used only for forwarding packets or determining location, never for identification. Address: An object that with mixed semantics, where it is sometimes used for identity and sometimes used for packet forwarding. Examples include but are not limited to IP addresses, which are sometimes used to forward packets and sometimes used for identity (e.g. in TCP session state). RLOC: An object used for forwarding packets in the LISP protocols. Scoped Locator: A locator that has non-global scope. Note that a scoped locator only has location semantics, never identification semantics. Scoped Identifier: An identifier with non-global scope. Note that a scoped identifier only has identity semantics, never location semantics. Identity: A possible property of an object. Addresses and Identifiers are examples of objects that have identity semantics. Location: A possible property of an object. Addresses and Locators are examples of objects that have location semantics. Identifier/Locator split: A class of network protocol that has no addresses, and only has (pure) identifiers and (pure) locators. Multi-Address split: A class of network protocol where one type of address is used for forwarding in one portion of the internetwork and a different type of address is used for forwarding in a different portion of the internetwork. Simple NAT is not an example of a multi-address split, since the same *type* of address (IPv4 xor IPv6) is used in all routing domains. EOF _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jun 10 13:24: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 1HxR8b-00047x-Lc; Sun, 10 Jun 2007 13:23:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxR8Z-00047s-VR for ram@iab.org; Sun, 10 Jun 2007 13:23:35 -0400 Received: from xmail02.myhosting.com ([168.144.250.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxR8Y-0005LU-Nx for ram@iab.org; Sun, 10 Jun 2007 13:23:35 -0400 Received: (qmail 13063 invoked from network); 10 Jun 2007 17:23:34 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Jun 2007 17:23:33 -0000 Message-ID: <466C3391.9010908@cisco.com> Date: Sun, 10 Jun 2007 13:23:29 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: [RAM] Crisper Terminology References: In-Reply-To: X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Tony Li , HeinerHummel@aol.com, rja@extremenetworks.com, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I can only speak for the RRG: the mobility implications of the Loc/ID >> split are still very much on the table. > > And ditto for the LISP designers. All the discussions I've seen say that "fast mobility" is off the table for LISP. Has this changed? :-) 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 iD8DBQFGbDORER27sUhU9OQRAj1BAJ4qpAw0rh3i9XHYEwvMJS53m8EggwCg2KL1 fpub1YnZ6pWfZ9C1OpSaI7g= =teiC -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jun 10 14:17:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxRxV-0003Av-Ic; Sun, 10 Jun 2007 14:16:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxRxU-0003Aq-QO for ram@iab.org; Sun, 10 Jun 2007 14:16:12 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxRxT-0000Nr-Gs for ram@iab.org; Sun, 10 Jun 2007 14:16:12 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 Jun 2007 11:16:11 -0700 X-IronPort-AV: i="4.16,406,1175497200"; d="scan'208"; a="162082892:sNHT41092875" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5AIGBaG020413; Sun, 10 Jun 2007 11:16:11 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5AIG820013837; Sun, 10 Jun 2007 18:16:08 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); Sun, 10 Jun 2007 11:16:08 -0700 Received: from [192.168.0.3] ([10.21.116.103]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Jun 2007 11:16:08 -0700 In-Reply-To: <466C3391.9010908@cisco.com> References: <466C3391.9010908@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <99ED413A-9288-48D8-8B60-B7A8F8F15E01@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Crisper Terminology Date: Sun, 10 Jun 2007 11:16:13 -0700 To: Russ White X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Jun 2007 18:16:08.0191 (UTC) FILETIME=[6AAD88F0:01C7AB8B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=506; t=1181499371; x=1182363371; 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]=20Crisper=20Terminology |Sender:=20; bh=J2ETonpwlT5UqLTk4giP/KzVAUDhRtdwfESAQfLuEx4=; b=SoIIERfQJ8S9UTgbBBM+Lyldc+siFRjsIQZ0IRYxJnnjDNnspQTRU74m68MT+mJ2169Yj/EQ EO06Lj9QNv7f4ZVeSLCkYLmlPmr24qRENH2/Hc+8rTZoUfkXw5m3J40RR91TIsO5XNsZ07Ettu VIQi5BpigP2P+xRkslNGUMkcU=; 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Tony Li , HeinerHummel@aol.com, rja@extremenetworks.com, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > All the discussions I've seen say that "fast mobility" is off the > table > for LISP. Has this changed? Nothing has changed. We have an idea how to do it at the expense of / 32s (for IPv4) locator entries in the ETR (and only the ETR). But we want to focus on the more pressing issues first. With enough trust anything can fly. But using LISP for fast mobility can work at the data-plane (with the proviso above) but definitely don't want it as part of the mapping service. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 11 07:54: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 1HxiSl-0005ez-GE; Mon, 11 Jun 2007 07:53:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxiSj-0005ei-E0 for ram@iab.org; Mon, 11 Jun 2007 07:53:33 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxiSh-0000yL-VW for ram@iab.org; Mon, 11 Jun 2007 07:53:33 -0400 Received: from pc6 (1Cust249.tnt29.lnd3.gbr.da.uu.net [62.188.120.249]) by blaster.systems.pipex.net (Postfix) with SMTP id AB731E000263; Mon, 11 Jun 2007 12:53:28 +0100 (BST) Message-ID: <003c01c7ac16$28201e40$0601a8c0@pc6> From: "tom.petch" To: , "RJ Atkinson" References: <9027C973-70C4-437A-9182-986063D7C7A8@extremenetworks.com> Subject: Re: [RAM] some draft proposed definitions Date: Mon, 11 Jun 2007 12:48:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I read the first definition and parted company with you:-( The way I see it: Identity is an abstract concept of a something that exists (real or virtual) that can be meaningfully differentiated from other somethings of the same ilk. Identifier is what we may then use to differentiate one something from another, within some set of identifiers (a namespace perhaps). Hence identifier can be applied to a stack, a node, a locality, a link, a port, a Universal Resource, ....... I believe we need this abstraction (and perhaps engineering struggles to deal with abstract concepts) in this dicussion eg by turning identifier/location split into stack identifier/location identifier split; which I think would make for a more focussed discussion. And I would find the ccamp I-D alluded to earlier clearer if it used identifier in place of address; it is all about identifiers. Tom Petch ----- Original Message ----- From: "RJ Atkinson" To: Sent: Sunday, June 10, 2007 6:12 PM Subject: [RAM] some draft proposed definitions > > Here is a draft proposal for terminology, with the goal > being greater clarity of communication. This is a starting > point, not an all-inclusive list. > > Yours, > > Ran > > Identifier: An object that is used only for identification, > never for forwarding packets or determining location. > > ID: Abbreviation for Identifier. > > Locator: An object that is used only for forwarding packets > or determining location, never for identification. > > Address: An object that with mixed semantics, where it is > sometimes used for identity and sometimes used > for packet forwarding. Examples include but are > not limited to IP addresses, which are sometimes > used to forward packets and sometimes used for > identity (e.g. in TCP session state). > > RLOC: An object used for forwarding packets > in the LISP protocols. > > Scoped Locator: A locator that has non-global scope. Note that > a scoped locator only has location semantics, > never identification semantics. > > Scoped Identifier: An identifier with non-global scope. Note that > a scoped identifier only has identity semantics, > never location semantics. > > Identity: A possible property of an object. Addresses and > Identifiers are examples of objects that have > identity semantics. > > Location: A possible property of an object. Addresses and > Locators are examples of objects that have > location semantics. > > Identifier/Locator split: A class of network protocol that > has no addresses, and only has (pure) identifiers > and (pure) locators. > > Multi-Address split: A class of network protocol where > one type of address is used for forwarding in one > portion of the internetwork and a different type > of address is used for forwarding in a different > portion of the internetwork. Simple NAT is not > an example of a multi-address split, since the > same *type* of address (IPv4 xor IPv6) is used > in all routing domains. > > EOF > _______________________________________________ > 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 Jun 11 09:01: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 1HxjV1-0001lt-JJ; Mon, 11 Jun 2007 08:59:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxjV0-0001lo-Gx for ram@iab.org; Mon, 11 Jun 2007 08:59:58 -0400 Received: from web58701.mail.re1.yahoo.com ([66.196.100.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxjV0-0007Or-4R for ram@iab.org; Mon, 11 Jun 2007 08:59:58 -0400 Received: (qmail 16298 invoked by uid 60001); 11 Jun 2007 12:57:55 -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=ZfdmGCc9I70mc/46hGIQAd/DMVhgMKmTI5TxYl5X/cCHO4YZstnrDst9foTxo/O5me/m5p1RjBHgVb366G0WSFG/5hfFkGSxT9gyZkptnXGHYD72upienVBykr82JXtmvKPIAWgY0XPGtwO0oin5A9ibq6H9mmHpjVm2CpQ+sJ0=; X-YMail-OSG: pRdTe7MVM1k7IHIUPIsZfgtY0.pvZqQjmCzc2i_h5DlepXMqUvD.m9TsugdO27kbsfL0tR89ARWWROP2VMpMak6NSE9n6GRnxjQ_6yFKrU_UXHKerjQZPonA1DLe Received: from [207.107.50.100] by web58701.mail.re1.yahoo.com via HTTP; Mon, 11 Jun 2007 05:57:54 PDT Date: Mon, 11 Jun 2007 05:57:54 -0700 (PDT) From: Peter Sherbin Subject: Re: [RAM] some draft proposed definitions To: RJ Atkinson , ram@iab.org In-Reply-To: <9027C973-70C4-437A-9182-986063D7C7A8@extremenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <57642.15023.qm@web58701.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 > terminology...with the goal being greater clarity of communication. For clarity we may want to start with basics instituting only two properties for an entity, i.e. an Identifier to permanently name it and a Locator to describe its current location. The identifier never changes. The locator changes as the entity moves from one locator to another. The name is globally unique hence the combination ID + Locator is also always unique. Locators may have a hierarchy and they do not necessarily have to be unique. Having only the above two (ID & Loc) eliminates a need for an address (which equals a locator), a scoped locator and a scoped identifier. Thanks, Peter --- RJ Atkinson wrote: > > Here is a draft proposal for terminology, with the goal > being greater clarity of communication. This is a starting > point, not an all-inclusive list. > > Yours, > > Ran > > > > > Identifier: An object that is used only for identification, > never for forwarding packets or determining location. > > ID: Abbreviation for Identifier. > > Locator: An object that is used only for forwarding packets > or determining location, never for identification. > > Address: An object that with mixed semantics, where it is > sometimes used for identity and sometimes used > for packet forwarding. Examples include but are > not limited to IP addresses, which are sometimes > used to forward packets and sometimes used for > identity (e.g. in TCP session state). > > RLOC: An object used for forwarding packets > in the LISP protocols. > > Scoped Locator: A locator that has non-global scope. Note that > a scoped locator only has location semantics, > never identification semantics. > > Scoped Identifier: An identifier with non-global scope. Note that > a scoped identifier only has identity semantics, > never location semantics. > > Identity: A possible property of an object. Addresses and > Identifiers are examples of objects that have > identity semantics. > > Location: A possible property of an object. Addresses and > Locators are examples of objects that have > location semantics. > > Identifier/Locator split: A class of network protocol that > has no addresses, and only has (pure) identifiers > and (pure) locators. > > Multi-Address split: A class of network protocol where > one type of address is used for forwarding in one > portion of the internetwork and a different type > of address is used for forwarding in a different > portion of the internetwork. Simple NAT is not > an example of a multi-address split, since the > same *type* of address (IPv4 xor IPv6) is used > in all routing domains. > > EOF > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 11 09:41: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 1Hxk7s-0000ze-U7; Mon, 11 Jun 2007 09:40:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxk7r-0000zX-5v for ram@iab.org; Mon, 11 Jun 2007 09:40:07 -0400 Received: from [2001:470:1:1:230:48ff:fe74:fd02] (helo=bender-mail.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxk7p-0004Bq-LO for ram@iab.org; Mon, 11 Jun 2007 09:40:07 -0400 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id B05617DCB for ; Mon, 11 Jun 2007 06:39:59 -0700 (PDT) Received: from JMHLap3.joelhalpern.com (jupiter.inet.qwest.net [67.133.255.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 1A7807DC9 for ; Mon, 11 Jun 2007 06:39:59 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Jun 2007 09:39:55 -0400 To: ram@iab.org From: "Joel M. Halpern" Subject: Re: [RAM] some draft proposed definitions In-Reply-To: <9027C973-70C4-437A-9182-986063D7C7A8@extremenetworks.com> References: <9027C973-70C4-437A-9182-986063D7C7A8@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070611133959.1A7807DC9@bender.tigertech.net> 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=1.8 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO, MSGID_FROM_MTA_ID X-Spam-Level: * X-Spam-Score: 1.8 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Looking at these definitions, and trying to think through more cases, I don't think that this actually captures the distinction, at least as I think of it. And I suspect that issue is why people react differently to various proposals in which IDs are also used for forwarding. Lets look at two closely related examples: Is an IEEE 48 bit "address" really an identifier, a locator, or a hybrid. As far as I can tell, it is strictly an identifier. It is assigned to a particular thing in a way that has no regard to where that thing is in any topology. However, being excessively clever engineers, we have then built solutions which allow us to forward packets based on that identiifers. Sometimes even very large solutions. (bridging in all its myriad forms.) That usage does not change the nature of the field. And before one argues that the MAC was layer 2, not layer 3, remember that OSI routing did exactly the same thing with the lower bytes of the NSAP within an area. That potion was an identifier. It stayed the same when the system moved (even if it moved between areas.) Hence, I think the difference between an Identifier and a Locator is in the semantics, not in whether it can be used to deliver packets. It doesn't seem to me that an identifier suddenly becomes a locator if in some region we choose to keep track of where the identifier can be found. To take the extreme case, some researchers have proposed systems that would use topologically insensitive identifiers for routing on systems of the scale of the internet. Without regard to the actually usability of the specific solutions, I think those things used for the end-points would still be identifiers, even if the entire system were forwarding packets based on them. The bit strings in that case have no location semantics in any topology that I can find. Yours, Joel M. Halpern At 12:12 PM 6/10/2007, RJ Atkinson wrote: >Identifier: An object that is used only for identification, > never for forwarding packets or determining location. > >ID: Abbreviation for Identifier. > >Locator: An object that is used only for forwarding packets > or determining location, never for identification. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 11 10: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 1HxkeS-0002Ut-8Y; Mon, 11 Jun 2007 10:13:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxkeQ-0002Ug-P1 for ram@iab.org; Mon, 11 Jun 2007 10:13:46 -0400 Received: from eastrmmtao105.cox.net ([68.230.240.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxkeQ-0002A4-DR for ram@iab.org; Mon, 11 Jun 2007 10:13:46 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070611141345.PRWL8837.eastrmmtao105.cox.net@eastrmimpo01.cox.net> for ; Mon, 11 Jun 2007 10:13:45 -0400 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id AEDl1X00P0pnMhQ0000000; Mon, 11 Jun 2007 10:13:45 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Mon, 11 Jun 2007 10:13:44 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [RAM] revised draft proposed definitions X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here is a revised draft proposal for terminology, with the goal being greater clarity of communication. This is still not fully cooked yet. No terminology will be perfect; the goal here is to come up with something that most folks can tolerate and that is "good enough" to clarify our discussions (here and in related fora such as the IRTF Routing RG). Thanks to Dino, Scott, and Joel for their offlist feedback, some of which is reflected below. One good question raised off-list is how to classify an IEEE MAC in this terminology. On the one hand, an IEEE MAC does not really have any location embedded inside it. IEEE MAC values belong to the end system interface and remain constant even if the interface's point of attachment changes (i.e. the end system moves location), so they could be called an Identifier. An IEEE MAC contains several items of information [Manufacturer prefix + scope bit (global/local) + multicast/unicast bit + end system value]. The "end system value" indirectly might imply when the system was manufactured, but is otherwise entirely opaque. On the other hand, the IEEE MAC is used directly (feed a Destination MAC into a table and get back which I/O port(s) to transmit it upon) to bridge frames within a layer-2 infrastructure. Yours, Ran Identifier: An object that is used only for identification, never for forwarding packets or determining location. Identifiers might exist at different protocol layers. For example, a fully-qualified domain name is one sort of Identifier. The EUI-64 in the low-order bits of an IPv6 address might be an Identifier, for example in an proposed protocol of the "8+8" class, though that would be a different kind of identifier than an FQDN. ID: Abbreviation for Identifier. See "Identifier" entry. Locator: An object that is used only for forwarding packets or determining location, never for identification. Address: An object that with mixed semantics, where it is sometimes used for identity and sometimes used for packet forwarding. Examples include, but are not limited to, IP addresses, which are sometimes used to forward packets and sometimes used for node identity (e.g. in TCP session state). LISP RLOC: An object used for forwarding packets in the LISP protocol proposal. This is typically for forwarding outside of an edge site. LISP EID: An object that has scoped location semantics (e.g. used for location when inside an edge site) and has end-to-end identity semantics. Since it has mixed semantics, this is a kind of address, rather than being a pure identifier. Scoped Locator: A locator that has non-global scope. Note that a scoped locator only has location semantics, never identification semantics. Scoped Identifier: An identifier with non-global scope. Note that a scoped identifier only has identity semantics, never location semantics. Identity: A possible property of an object. Addresses and Identifiers are examples of objects that have identity semantics. Identity can exist at multiple protocol layers. One might compose a transport- layer identity from an IP address and a TCP port number or from a node identifier and a TCP port number -- for example. Location: A possible property of an object. Addresses and Locators are examples of objects that have location semantics. Location also can exist at multiple protocol layers; most notably, a node typically has both a link-layer location and a congruent but distinct network-layer location at a given instant in time. Identifier/Locator split: A class of network protocol that has no addresses, and only has (pure) identifiers and (pure) locators. Proposals in the GSE/8+8 class of solution might be examples of this, depending on the details of the proposal. Multi-Address split: A class of network protocol where one type of address is used for forwarding in one portion of the internetwork and a different type of address is used for forwarding in a different portion of the internetwork. Simple NAT is not an example of a multi-address split, since the same *type* of address (IPv4 xor IPv6) is used in all routing domains. LISP might be an example of a Multi-Address split. EOF _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 11 11:28: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 1Hxlo8-0003AI-8w; Mon, 11 Jun 2007 11:27:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxlo6-00039o-Hv for ram@iab.org; Mon, 11 Jun 2007 11:27:50 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxlo5-0003Vc-9n for ram@iab.org; Mon, 11 Jun 2007 11:27:50 -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.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5BFRgeL004711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Jun 2007 10:27:43 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5BFRgY7029826; Mon, 11 Jun 2007 10:27:42 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5BFRP5P029226; Mon, 11 Jun 2007 10:27:30 -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, 11 Jun 2007 08:27:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] (no subject) Date: Mon, 11 Jun 2007 08:27:23 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED866@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <776D3684-8C59-459F-86AC-EE7D05A8855A@extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] (no subject) Thread-Index: AcereFA6trPTFnJFQ8St9OYK8TiVTQAxHSFQ References: <776D3684-8C59-459F-86AC-EE7D05A8855A@extremenetworks.com> From: "Templin, Fred L" To: "RJ Atkinson" , X-OriginalArrivalTime: 11 Jun 2007 15:27:24.0237 (UTC) FILETIME=[02BE7FD0:01C7AC3D] 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 > > Correct me if I am wrong: the IPv6 address space > > does not INCLUDE the IPv4 address space. >=20 > Not correct. There is a special prefix in IPv6 that says > the low-order 32 bits are an IPv4 address. [RFC-4291, > Section 2.5.5.2, Page 10-11] Or even ([RFC4214], Section 6). 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 Jun 11 11:28: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 1HxloK-0003EL-NT; Mon, 11 Jun 2007 11:28:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxloJ-0003Cp-3Y for ram@iab.org; Mon, 11 Jun 2007 11:28:03 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxloH-0003Wi-Qx for ram@iab.org; Mon, 11 Jun 2007 11:28:03 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2007 17:28:02 +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 l5BFS1oO020216; Mon, 11 Jun 2007 17:28:01 +0200 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp4748.cisco.com [10.61.82.139]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5BFRuDR027018; Mon, 11 Jun 2007 15:28:00 GMT Message-ID: <466D69FC.3010003@cisco.com> Date: Mon, 11 Jun 2007 16:27:56 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] revised draft proposed definitions References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> In-Reply-To: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.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=939; t=1181575681; x=1182439681; 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]=20revised=20draft=20proposed=20definitions |Sender:=20; bh=KIktPjjNZNAluP6nPYre1Kt2YwpH0InTxGt/Z90F6hc=; b=fND1TWwi/+HHm2cEshJ+rxBOscHRYql6tUtOB3Cyu5Be8m5YLKjryUio3Da8Mu0KwbklPvn1 cyu2IN9YkjjobXTyg7SIQTnFmuAR5vJR7GwdPLDts9K4bM4HiHBMwmDJ; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Ran, I'd like to think that we all get it. Perhaps I'm wrong. Here are some suggested changes, just in case: > > Identifier: An object that is used only for identification, > never for forwarding packets or determining location. > Just as a matter of principle, I think it's best to define what these things are, rather than what they're not. Never is a long time, and quite frankly it's not very descriptive. Better to say something like, "An identifier [or the thing it identifies] may change its location at any time, and may in fact be present in multiple locations." > > > > Locator: An object that is used only for forwarding packets > or determining location, never for identification. Same comment only in reverse ;-) "A locator denotes presence at a specific point in the network. When one's location within a network changes, one locator changes". Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 11 11:28: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 1Hxlo8-0003AI-8w; Mon, 11 Jun 2007 11:27:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxlo6-00039o-Hv for ram@iab.org; Mon, 11 Jun 2007 11:27:50 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxlo5-0003Vc-9n for ram@iab.org; Mon, 11 Jun 2007 11:27:50 -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.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5BFRgeL004711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Jun 2007 10:27:43 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5BFRgY7029826; Mon, 11 Jun 2007 10:27:42 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5BFRP5P029226; Mon, 11 Jun 2007 10:27:30 -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, 11 Jun 2007 08:27:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] (no subject) Date: Mon, 11 Jun 2007 08:27:23 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED866@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <776D3684-8C59-459F-86AC-EE7D05A8855A@extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] (no subject) Thread-Index: AcereFA6trPTFnJFQ8St9OYK8TiVTQAxHSFQ References: <776D3684-8C59-459F-86AC-EE7D05A8855A@extremenetworks.com> From: "Templin, Fred L" To: "RJ Atkinson" , X-OriginalArrivalTime: 11 Jun 2007 15:27:24.0237 (UTC) FILETIME=[02BE7FD0:01C7AC3D] 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 > > Correct me if I am wrong: the IPv6 address space > > does not INCLUDE the IPv4 address space. >=20 > Not correct. There is a special prefix in IPv6 that says > the low-order 32 bits are an IPv4 address. [RFC-4291, > Section 2.5.5.2, Page 10-11] Or even ([RFC4214], Section 6). 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 Jun 11 11:28: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 1HxloK-0003EL-NT; Mon, 11 Jun 2007 11:28:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxloJ-0003Cp-3Y for ram@iab.org; Mon, 11 Jun 2007 11:28:03 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxloH-0003Wi-Qx for ram@iab.org; Mon, 11 Jun 2007 11:28:03 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2007 17:28:02 +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 l5BFS1oO020216; Mon, 11 Jun 2007 17:28:01 +0200 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp4748.cisco.com [10.61.82.139]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5BFRuDR027018; Mon, 11 Jun 2007 15:28:00 GMT Message-ID: <466D69FC.3010003@cisco.com> Date: Mon, 11 Jun 2007 16:27:56 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] revised draft proposed definitions References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> In-Reply-To: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.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=939; t=1181575681; x=1182439681; 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]=20revised=20draft=20proposed=20definitions |Sender:=20; bh=KIktPjjNZNAluP6nPYre1Kt2YwpH0InTxGt/Z90F6hc=; b=fND1TWwi/+HHm2cEshJ+rxBOscHRYql6tUtOB3Cyu5Be8m5YLKjryUio3Da8Mu0KwbklPvn1 cyu2IN9YkjjobXTyg7SIQTnFmuAR5vJR7GwdPLDts9K4bM4HiHBMwmDJ; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Ran, I'd like to think that we all get it. Perhaps I'm wrong. Here are some suggested changes, just in case: > > Identifier: An object that is used only for identification, > never for forwarding packets or determining location. > Just as a matter of principle, I think it's best to define what these things are, rather than what they're not. Never is a long time, and quite frankly it's not very descriptive. Better to say something like, "An identifier [or the thing it identifies] may change its location at any time, and may in fact be present in multiple locations." > > > > Locator: An object that is used only for forwarding packets > or determining location, never for identification. Same comment only in reverse ;-) "A locator denotes presence at a specific point in the network. When one's location within a network changes, one locator changes". Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 11 11:45: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 1Hxm4B-0007Ak-2C; Mon, 11 Jun 2007 11:44:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxm49-0007Ac-PZ for ram@iab.org; Mon, 11 Jun 2007 11:44:25 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxm48-0005qT-6T for ram@iab.org; Mon, 11 Jun 2007 11:44:25 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id AE9642000186; Mon, 11 Jun 2007 17:44:23 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jw6j4bJT+EvD; Mon, 11 Jun 2007 17:44:23 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8FC342000178; Mon, 11 Jun 2007 17:44:13 +0200 (CEST) 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] some draft proposed definitions Date: Mon, 11 Jun 2007 17:44:09 +0200 Message-ID: In-Reply-To: <20070611133959.1A7807DC9@bender.tigertech.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] some draft proposed definitions Thread-Index: AcesLiEWwJCwt/HLRRyVmxWgBRNtPQADiCkQ References: <9027C973-70C4-437A-9182-986063D7C7A8@extremenetworks.com> <20070611133959.1A7807DC9@bender.tigertech.net> From: "Marcus Brunner" To: "Joel M. Halpern" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Joel, With the term topology you bring up the issue. A location can actually = be specified in at least two different ways. With a 1) topology-bound locator (better term welcome), which is=20 - only valid together with a certain topology (examples are IP address, = postal address, ..). - is structured, looking into part of the address you are able to get = nearer to the destination (country, city, street, street number, ...) - you don't need to know the detailed global topology (e.g., internet) 2) coordinate-bounded locator, which is - a location in a coordinate system (like the 2-dimensional geographic = coordinates) - requires the map/other positioning systems to find the place where you = are and a system to find out what direction to go=20 - some ad-hoc routing system propose geographic routing Kind regards, Marcus --------------------------------------------------- Dr. Marcus Brunner Network Laboratories =20 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 > Sent: Monday, June 11, 2007 3:40 PM > To: ram@iab.org > Subject: Re: [RAM] some draft proposed definitions >=20 > Looking at these definitions, and trying to think through=20 > more cases, I don't think that this actually captures the=20 > distinction, at least as I think of it. > And I suspect that issue is why people react differently to=20 > various proposals in which IDs are also used for forwarding. >=20 > Lets look at two closely related examples: > Is an IEEE 48 bit "address" really an identifier, a locator,=20 > or a hybrid. As far as I can tell, it is strictly an=20 > identifier. It is assigned to a particular thing in a way=20 > that has no regard to where that thing is in any topology. =20 > However, being excessively clever engineers, we have then=20 > built solutions which allow us to forward packets based on=20 > that identiifers. Sometimes even very large solutions. =20 > (bridging in all its myriad forms.) That usage does not=20 > change the nature of the field. > And before one argues that the MAC was layer 2, not layer 3,=20 > remember that OSI routing did exactly the same thing with the=20 > lower bytes of the NSAP within an area. That potion was an=20 > identifier. It stayed the same when the system moved (even=20 > if it moved between areas.) >=20 > Hence, I think the difference between an Identifier and a=20 > Locator is in the semantics, not in whether it can be used to=20 > deliver packets. It doesn't seem to me that an identifier=20 > suddenly becomes a locator if in some region we choose to=20 > keep track of where the identifier can be found. To take the=20 > extreme case, some researchers have proposed systems that=20 > would use topologically insensitive identifiers for routing=20 > on systems of the scale of the=20 > internet. Without regard to the actually usability of the specific=20 > solutions, I think those things used for the end-points would=20 > still be identifiers, even if the entire system were=20 > forwarding packets based on them. The bit strings in that=20 > case have no location semantics in any topology that I can find. >=20 > Yours, > Joel M. Halpern >=20 > At 12:12 PM 6/10/2007, RJ Atkinson wrote: > >Identifier: An object that is used only for identification, > > never for forwarding packets or determining=20 > location. > > > >ID: Abbreviation for Identifier. > > > >Locator: An object that is used only for forwarding packets > > or determining location, never for identification. >=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 Jun 11 12:09: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 1HxmRY-0003QM-7c; Mon, 11 Jun 2007 12:08:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxmQX-0002d7-4f for ram@iab.org; Mon, 11 Jun 2007 12:07:33 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxmMg-0000XO-Ni for ram@iab.org; Mon, 11 Jun 2007 12:03:35 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 22D62872D4; Mon, 11 Jun 2007 12:03:32 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Crisper Terminology Message-Id: <20070611160332.22D62872D4@mercury.lcs.mit.edu> Date: Mon, 11 Jun 2007 12:03:32 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 >>> LISP is a dual-locator scheme, rather than an ID-Locator split. >> the transport layer needs a name to distinguish the entity at the >> other end with which it is communicating. That name is what we are >> calling the "identifier" ... any bit-string/name which serves this >> purpose of naming the transport-layer entity at the other end is, >> *by definition*, an "identifier". It may *also* have some locational >> semantics > There is a perfectly good a name for objects with both identification > and location semantics. This community generally calls them > addresses. That's an interesting point. I have in the past generally tried to discourage use of the term "address" because it means different things to different people, and use of it is therefore often confusing. As an example, the term 'locator' was introduced to the lexicon by the Nimrod project because in Nimrod, 'addresses' (which in Nimrod are long, and variable-length) are not necessarily carried in all packets, and whenever people heard the word 'address' they kept assuming they were in every packet (i.e. inefficient processing), no matter how hard we tried to get it through that they were not. (And of course the current assumed main point of the definition of 'locator', i.e. meaning 'a name with topological semantics', wasn't really the point of what differentiated a 'locator' from an 'address'.) So, I'm perfectly happy if you and I use the term 'address' to mean 'a name that is used at the internetwork level to name an interface, and has location semantics; and is also a name which is used at the transport layer to name end-end entities'. However, we can't assume that when we use the term 'address', other people will understand that meaning... Anyway, using that terminology, LISP has a locator and an address, but the 'interface naming with location semantics' part of the the latter has only local scope/utility. > Most of this community uses "Identifier" to mean a pure Identifier -- > with no locational semantics -- and has had that meaning for about a > decade now. Right, but there's another axis we need to be worrying about, past the locational/non-locational, which is 'what kind of thing are these names naming'. And to me (perhaps because I started using 'identifier' as part of the phrase 'endpoint identifier') 'identifier' has always *also* meant 'names a transport entity'; and 'locator' has always also meant 'names an internetwork-level entity'. Which is the main reason why I always objected when you said that "LISP is a dual-locator scheme, rather than an ID-Locator split", because to me one of those names was, in part, always an identifier, i.e. the name of the transport entity. > the best/fastest way to figure out the issues is to have clear, crisp > terminology. That will certainly help. Unfortunately, at the moment it seems to me that we have too few terms (or too many concepts :-). First, let's look at the attributional axes we need to cover: - Locational/non-locational - Internetwork/transport - Interface/'endpoint' Of course, some people might argue that the latter two are identical, but I have heard people argue for locational names for endpoints, so I would suggest we not collapse them together. Then, in theory at least, one could have one term for each possible choice, so a Nimrod 'locator' is locational/internetwork/interface. But of course IPv4 addresses are *both* for at least two of the three! So really it's three choices for each: - Locational/non-locational/both - Internetwork/transport/both - Interface/'endpoint'/both Even assuming the last two are identical, that leaves us with nine possibile ways of mixing those attributes; we could, in theory, have a term for each possible combination... Some of the combinations are not worth naming, of course, which simplifies things somewhat. However, we still have a lot more potentiall useful combinations than we have terms. Also, then there are some subsidiary ones we haven't discussed yet: - In all packets/not-in-all-packets - The field looked at by the switches to forward the packet (which I have in the past called the 'forwarding tag') So that a Nimrod 'locator' is in fact neither in all packets, nor a 'forwarding tag'... But I think this makes clear we can't have a term for each possible combination of naming attributes. I don't have an immediate suggestion for the solution here. Even if you and I were to come up with a wonderful set of crisp definitions for 'locator', 'address', etc, there's no way we will be able to get everyone to agree on them. I think the best we can all do, when using a term such as 'identifier' or 'locator', is to clearly indicate what we mean by that term, using the various attributional axes I laid out above - and there are probably other ones I have missed (in-a-directory/non-in-a-directory, etc, etc). Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 11 16:05: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 1Hxq8S-0008Dd-Og; Mon, 11 Jun 2007 16:05:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxq8S-0008DY-7s for ram@iab.org; Mon, 11 Jun 2007 16:05:08 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxq8Q-0006Wa-Rz for ram@iab.org; Mon, 11 Jun 2007 16:05:08 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2007 13:05:06 -0700 X-IronPort-AV: i="4.16,409,1175497200"; d="scan'208"; a="162685172:sNHT43778340" 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 l5BK56Mu027296; Mon, 11 Jun 2007 13:05:06 -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 l5BK4ttf014077; Mon, 11 Jun 2007 20:05:02 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); Mon, 11 Jun 2007 13:04:58 -0700 Received: from [171.70.254.34] ([171.70.254.34]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 13:04:57 -0700 Message-ID: <466D7FF5.8060302@employees.org> Date: Mon, 11 Jun 2007 13:01:41 -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.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [RAM] Crisper Terminology References: <20070608162021.1266686AF0@mercury.lcs.mit.edu> <1061608D-5E5D-45E9-965C-9E66B4C41E95@extremenetworks.com> <466A4BCE.4010208@gmail.com> In-Reply-To: <466A4BCE.4010208@gmail.com> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2007 20:04:58.0022 (UTC) FILETIME=[C92C6C60:01C7AC63] Authentication-Results: sj-dkim-2; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 06/09/2007 02:42 AM, Brian E Carpenter allegedly wrote: > I'd be tempted to agree with that, but I just had occasion to > review draft-ietf-ccamp-gmpls-addressing-07.txt, and found my head > spinning rapidly on exactly this question. The problem there is separation of planes. Router and Forwarder are somewhat independent, thus Control and Forwarding (Data) Plane are as well. In GMPLS you have an independent control plane, and an independent control plane requires independent transport names. The IP component of control plane transport, has its own locators, and forwards packets which carry in them identifiers of components of the (possibly non-IP) forwarding plane. I believe it's right to say that the "addresses" in the forwarding plane are really identifiers, but it depends how path setups are done. However, it seems that those identifiers are not only system identifiers but also interface or link identifiers. > Well, if we use OSI formalism, we'd have to say that the transport > address is the network address concatenated with the port number. > There was a fairly clear model for layered endpoint addressing in > OSI, and it still a valid thinking aid IMHO. > > 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 Mon Jun 11 16:05: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 1Hxq92-0008NW-9M; Mon, 11 Jun 2007 16:05:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxq90-0008N4-Ng for ram@iab.org; Mon, 11 Jun 2007 16:05:42 -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 1Hxq8z-0006dj-Vj for ram@iab.org; Mon, 11 Jun 2007 16:05:42 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 11 Jun 2007 13:05:04 -0700 X-IronPort-AV: i="4.16,409,1175497200"; d="scan'208"; a="492621969:sNHT2389515330" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5BK544J029874; Mon, 11 Jun 2007 13:05:04 -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 l5BK4u20025968; Mon, 11 Jun 2007 20:05:04 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 13:04:55 -0700 Received: from [171.70.254.34] ([171.70.254.34]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 13:04:55 -0700 Message-ID: <466D7B18.4010305@employees.org> Date: Mon, 11 Jun 2007 12:40:56 -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.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [RAM] some draft proposed definitions References: <9027C973-70C4-437A-9182-986063D7C7A8@extremenetworks.com> <20070611133959.1A7807DC9@bender.tigertech.net> In-Reply-To: <20070611133959.1A7807DC9@bender.tigertech.net> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2007 20:04:55.0685 (UTC) FILETIME=[C7C7D350:01C7AC63] Authentication-Results: sj-dkim-1; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 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 06/11/2007 09:39 AM, Joel M. Halpern allegedly wrote: > Lets look at two closely related examples: > Is an IEEE 48 bit "address" really an identifier, a locator, or a > hybrid. As far as I can tell, it is strictly an identifier. It is > assigned to a particular thing in a way that has no regard to where that > thing is in any topology. However, being excessively clever engineers, > we have then built solutions which allow us to forward packets based on > that identiifers. Sometimes even very large solutions. (bridging in > all its myriad forms.) That usage does not change the nature of the field. Exacto. Ultimately you need a mapping to a nexthop. In 802.1d you map directly from identifier to nexthop. In other environments you map from a locator to a nexthop. Sometimes you need both, sometimes you it takes multiple lookups, sometimes you do multiple mappings at multiple points along a path, and so on (a locator need not be the ultimate end-system locator or even prefix -- it might be an intermediate point like a tunnel ingress). But how you get those mappings can be done by any means, using any kind of information, and the only thing you can be sure of is the nexthop. > Hence, I think the difference between an Identifier and a Locator is in > the semantics, not in whether it can be used to deliver packets. It > doesn't seem to me that an identifier suddenly becomes a locator if in > some region we choose to keep track of where the identifier can be > found. Right, it's about intended use. Just because something is used to map to a locator doesn't make it an identifier. There are two phases to routing, path discovery and path selection. Path discovery can be aided by dissemination of information and distributed processing (including most of the routing protocols we like). It can be done by probing (PNNI, PCEP, NUTSS etc.). It can be done by asking someone who knows more than you do (like DNS). In the case of SIP you start out with an identifier. You resolve that to a locator, and you send an INVITE including your identifier and locator as payload. In the case of LISP, you start out with a locator. At some point that locator is sent to "someone who knows more", as payload, to map to an ITR (another locator) and to a nexthop. This does not make the original locator an identifier. On 06/10/2007 12:12 PM, RJ Atkinson allegedly wrote: > Identifier: An object that is used only for identification, > never for forwarding packets or determining location. I like this except to avoid ambiguity I suggest leaving out "forwarding packets". > Locator: An object that is used only for forwarding packets > or determining location, never for identification. Certainly the last part is true, but locators are used for all sorts of things. I propose "A locator is a name intended to have topologically meaningful semantics, in order that it can be used to determine a next hop for a packet." That allows other uses. > Address: An object that with mixed semantics, where it is > sometimes used for identity and sometimes used > for packet forwarding. Examples include but are > not limited to IP addresses, which are sometimes > used to forward packets and sometimes used for > identity (e.g. in TCP session state). Only if we're talking about the current Internet. Let's avoid using this in new architecture discussions. > Scoped Locator: A locator that has non-global scope. Note that > a scoped locator only has location semantics, > never identification semantics. > > Scoped Identifier: An identifier with non-global scope. Note that > a scoped identifier only has identity semantics, > never location semantics. Don't like them. Everything has scope by nature. Sometimes that scope is global, sometimes not. Just because we've assumed global scope in the past doesn't mean that was the right thing to do. > Identity: A possible property of an object. Addresses and > Identifiers are examples of objects that have > identity semantics. Let's stay away from identity unless we really need it. I just spent two years listening to arguments about it. On 06/10/2007 23:34 PM, Tony Li allegedly wrote: > This would be a fine addition to the taxonomy draft, if it isn't there > already... Here is my current draft text. Lixia hasn't had a chance to hack it up. All comments appreciated ... :
A "name" is "an identifier (of no specific syntax or properties) for an object" . "Name" is a general term, and includes more specific subsets such as "locator" and "identifier".
A locator is a name intended to have topologically meaningful semantics, in order that it can be used to determine a next hop for a packet. Just because a locator is intended to be used in forwarding packets does not mean that it can be used to do so in every part of the Internet. Locators have scope. Even when a locator is out of its scope and thus cannot be used for forwarding (it cannot be resolved to a next hop), it is still a locator if it is intended to be used in that way. Locators which cannot be resolved to a next hop are said to be "not routable". A locator may name an ultimate destination attachment point, or it may name an intermediate point on the way to that attachment point. For example, a locator may name a tunnel ingress point which can be used to reach the ultimate destination. It has been suggested that "locator" by itself implies global scope, and that if the scope of a locator concept is less than global, it must have an adjective associated with it, for example "routing locator". However, it has also been suggested that "locator" by itself is a generic term for all locators, regardless of scope. To be resolved.
An identifier is a name that is used for identification, never for determining location. It does not have topologically meaningful semantics. It names an endpoint of a communication. An "end system identifier" names the ???TBD??? layer for that end system. "ID" is an abbreviation for "identifier".
Before the idea of separation of identifier and locator became common, "address" was used primarily to refer to locator functions but also to identifier functions. Because the term is ambiguous, its use is deprecated except when talking about the current Internet It has been suggested that "address" should continue to be used for a name that functions as both a locator and an identifier. To be resolved.
_______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 11 16: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 1HxqAw-0000GF-BY; Mon, 11 Jun 2007 16:07:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxqAv-0000G8-8R for ram@iab.org; Mon, 11 Jun 2007 16:07:41 -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 1HxqAt-0006vs-Sv for ram@iab.org; Mon, 11 Jun 2007 16:07:41 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 11 Jun 2007 13:07:39 -0700 X-IronPort-AV: i="4.16,409,1175497200"; d="scan'208"; a="2549262:sNHT21089304" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5BK7dak028486; Mon, 11 Jun 2007 13:07: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 l5BK7dV1001575; Mon, 11 Jun 2007 20:07:39 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 13:07:38 -0700 Received: from [171.70.224.106] ([171.70.224.106]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 13:07:38 -0700 In-Reply-To: <466D69FC.3010003@cisco.com> References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> <466D69FC.3010003@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <715690CE-8527-4123-9A09-101FC7EDF5EC@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] revised draft proposed definitions Date: Mon, 11 Jun 2007 13:05:56 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Jun 2007 20:07:38.0491 (UTC) FILETIME=[28D20CB0:01C7AC64] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1263; t=1181592459; x=1182456459; 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]=20revised=20draft=20proposed=20definitions |Sender:=20; bh=5BVqvjA7RkVBMFLHkJ/MPd1vbqxdIeHSVSE/i5R3aXg=; b=GaCKQslUCEUMYbgd9hFLT2lJCEWfS4cFthXf/Bzie20cxpnpFoMzFVHnPD8vwCBGg34xVF2K HDj3E1kWW01jwhGiKL+ZTXuqRh46DTdfT3ufOW5SwGE5DPpY9WXw1F4G; 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: b19722fc8d3865b147c75ae2495625f2 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Jun 11, 2007, at 8:27 AM, Eliot Lear wrote: >> Identifier: An object that is used only for identification, >> never for forwarding packets or determining location. >> > Just as a matter of principle, I think it's best to define what > these things are, rather than what they're not. Never is a long > time, and quite frankly it's not very descriptive. Better to say > something like, "An identifier [or the thing it identifies] may > change its location at any time, and may in fact be present in > multiple locations." That still fails the test of describing what things are. What we want is to take a constructive approach: An identifier is an element of a namespace. There is a 1:1 mapping between the namespace and the entities being enumerated. >> Locator: An object that is used only for forwarding packets >> or determining location, never for identification. > > Same comment only in reverse ;-) "A locator denotes presence at a > specific point in the network. When one's location within a > network changes, one locator changes". Ok, but a locator does NOT denote reachability. Thus, a locator is a string of bits that indicates a topological location. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 11 16:32: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 1HxqYm-0007V6-Oq; Mon, 11 Jun 2007 16:32:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxqYl-0007Mr-CF for ram@iab.org; Mon, 11 Jun 2007 16:32:19 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxqYk-0004Hv-01 for ram@iab.org; Mon, 11 Jun 2007 16:32:19 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 8D38C240826; Mon, 11 Jun 2007 22:32:11 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 871A5106C4; Mon, 11 Jun 2007 22:30:28 +0200 (CEST) Date: Mon, 11 Jun 2007 22:30:28 +0200 From: Stephane Bortzmeyer To: RJ Atkinson Message-ID: <20070611203028.GA13021@sources.org> References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ram@iab.org Subject: [RAM] Re: revised draft proposed definitions X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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, Jun 11, 2007 at 10:13:44AM -0400, RJ Atkinson wrote a message of 110 lines which said: > Here is a revised draft proposal for terminology, I understand better when there are examples so let me suggest some and RAM people will tell me if I understood properly or if I'm completely and hopelessly lost. > Identifier: An object that is used only for identification, > never for forwarding packets or determining location. > > Identifiers might exist at different protocol layers. > For example, a fully-qualified domain name is one > sort of Identifier. OK > Locator: An object that is used only for forwarding packets > or determining location, never for identification. I was not able to find an example of a global locator, in the current IETF standards. Does anyone have an existing example? > Scoped Locator: A locator that has non-global scope. Note that > a scoped locator only has location semantics, > never identification semantics. A MPLS label is a scoped locator. Am I right? > Scoped Identifier: An identifier with non-global scope. Note that > a scoped identifier only has identity semantics, > never location semantics. A non-qualified domain name is OK for a scoped identifier? Or a Local Scope Identifier (LSI) (RFC 4423)? > Identifier/Locator split: A class of network protocol that > has no addresses, and only has (pure) identifiers > and (pure) locators. Proposals in the GSE/8+8 > class of solution might be examples of this, > depending on the details of the proposal. HIP too, no? _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 11 16:54: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 1Hxqu6-00009N-3u; Mon, 11 Jun 2007 16:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxqu4-00009D-4O for ram@iab.org; Mon, 11 Jun 2007 16:54:20 -0400 Received: from [2001:470:1:1:230:48ff:fe74:fd02] (helo=bender-mail.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxqu2-0000nK-NR for ram@iab.org; Mon, 11 Jun 2007 16:54:20 -0400 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id ACCE97DDA for ; Mon, 11 Jun 2007 13:54:14 -0700 (PDT) Received: from JMHLap3.joelhalpern.com (jupiter.inet.qwest.net [67.133.255.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 1A6427DD9 for ; Mon, 11 Jun 2007 13:54:14 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 11 Jun 2007 16:54:07 -0400 To: From: "Joel M. Halpern" Subject: RE: [RAM] some draft proposed definitions In-Reply-To: References: <9027C973-70C4-437A-9182-986063D7C7A8@extremenetworks.com> <20070611133959.1A7807DC9@bender.tigertech.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070611205414.1A6427DD9@bender.tigertech.net> 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=1.8 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO, MSGID_FROM_MTA_ID X-Spam-Level: * X-Spam-Score: 1.8 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 know how anyone else reads this, but to me both of those are values which provide a location in a topological space, i.e. Locators. And they have the property, as Elliot said, that if the device moves in the topology, the locator changes. Yours, Joel At 11:44 AM 6/11/2007, Marcus Brunner wrote: >Joel, > >With the term topology you bring up the issue. A location can >actually be specified in at least two different ways. With a > >1) topology-bound locator (better term welcome), which is >- only valid together with a certain topology (examples are IP >address, postal address, ..). >- is structured, looking into part of the address you are able to >get nearer to the destination (country, city, street, street number, ...) >- you don't need to know the detailed global topology (e.g., internet) > >2) coordinate-bounded locator, which is >- a location in a coordinate system (like the 2-dimensional >geographic coordinates) >- requires the map/other positioning systems to find the place where >you are and a system to find out what direction to go >- some ad-hoc routing system propose geographic routing > > >Kind regards, > >Marcus _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 11 17:09: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 1Hxr8u-0004P9-5u; Mon, 11 Jun 2007 17:09:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxr8t-0004P4-LH for ram@iab.org; Mon, 11 Jun 2007 17:09:39 -0400 Received: from imo-d21.mx.aol.com ([205.188.144.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxr8s-0003pX-9C for ram@iab.org; Mon, 11 Jun 2007 17:09:39 -0400 Received: from HeinerHummel@aol.com by imo-d21.mx.aol.com (mail_out_v38_r9.2.) id j.d39.b429a86 (41810); Mon, 11 Jun 2007 17:09:32 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Mon, 11 Jun 2007 17:09:32 EDT Subject: Re: [RAM] (no subject) To: rja@extremenetworks.com, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5014 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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="===============1533750681==" Errors-To: ram-bounces@iab.org --===============1533750681== Content-Type: multipart/alternative; boundary="-----------------------------1181596172" -------------------------------1181596172 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 10.06.2007 17:59:30 Westeurop=E4ische Normalzeit schreibt= =20 rja@extremenetworks.com: > Correct me if I am wrong: the IPv6 address space > does not INCLUDE the IPv4 address space. Not correct. There is a special prefix in IPv6 that says the low-order 32 bits are an IPv4 address. [RFC-4291, Section 2.5.5.2, Page 10-11] Thank you Ran > One for E.164 (instead of DNS mapping a la enum) ? Etc. etc. I believe that it might also be possible to algorithmically place an E.164 into an NSAP and then into an IPv6 address using the special prefix that means an NSAP is in the low-order bits of the IPv6 address. It isn't clear to me whether this is explicitly documented at present. My point here is: By catering multiple address families it becomes more =20 obvious that multicast-address range is the wrong way to indicate "p2mp =20 processing". Multicast address range is a bad design principle back from the= early=20 beginning. =20 The discussion on this RAM mailinglist has only Unicast in mind:-(=20 The really best solution however will improve the situation for all: p2p =20 Unicast, p2p Anycast, p2mp Multicast, mp2p, mp2mp.=20 =20 So let's be focused again on routing: =20 In an email from Lixia on 29.05.2007 05:57:14, _lixia@CS.UCLA.EDU_=20 (mailto:lixia@CS.UCLA.EDU) it says : Splitting prefixes is a simple and effective means to achieve traffic =20 engineering goals, and whoever needs to do it will do it. I believe a =20 scalable solution essentially lies on the ability to effectively (re)=20 aggregate prefixes. my answer was: ...or, just the opposite as I believe, on a design that removes the pressur= e=20 for doing prefix aggregation totally. =20 Then silence. =20 More then ten years ago we worked in the PNNI-WG of the ATM Forum. Georg =20 Swallow had already introduced the "UPLINK". A border-to-border node link =20 between two peer groups was supposed to be representated by some uplink. Tha= t =20 uplink was subject to be aggregated to some induced uplink, eventually sever= al =20 times in some recursive manner, and finally supposed =B4to become part of a=20= =20 "higher level horizontal link". The same applied to the neighboring side so=20= that =20 from either side the same border-to-border link had to wind up in the same =20 higher level horizontal link by either side.=20 =20 I was against that link/upling aggregation: I told the audience, when we will adjourn the meeting, we only have to kno= w=20 at which city, which hotel and which ballroom the next meeting will take=20 place, and every one is able to get there next time. Based on this thought=20= the=20 Aggregation Token was born, and the horrible topic of aggregating=20 links/uplinks was off the table. =20 The link/uplink aggregation would have caused, relatively, the same =20 scalability problem that this community is about to fight. So this is just=20= another=20 proof that there is no need to effectively (re) aggregate prefixes. =20 Heiner =20 =20 -------------------------------1181596172 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 10.06.2007 17:59:30 Westeurop=E4ische Normalzeit sch= reibt=20 rja@extremenetworks.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>>=20 Correct me if I am wrong: the IPv6 address space
> does not INCLUDE=20= the=20 IPv4 address space.

Not correct.  There is a special prefix in= =20 IPv6 that says
the low-order 32 bits are an IPv4 address. =20 [RFC-4291,
Section 2.5.5.2, Page 10-11]
Thank you Ran
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>
>  One for E.164 (instead of DNS mapping a la enum) ?= Etc.=20 etc.

I believe that it might also be possible to=20 algorithmically
place an E.164 into an NSAP and then into an IPv6=20 address
using the special prefix that means an NSAP is in the=20 low-order
bits of the IPv6 address.  It isn't clear to me=20 whether
this is explicitly documented at present.
My point here is: By catering multiple address families it becomes more= =20 obvious that multicast-address range  is the wrong way to indicate "p2m= p=20 processing". Multicast address range is a bad design principle back from the= =20 early beginning.
 
The discussion on this RAM mailinglist has only Unicast in mind:-(
The really best solution however will improve the situation for all: p2= p=20 Unicast, p2p Anycast, p2mp Multicast, mp2p, mp2mp.
 
So let's be focused again on routing:
 =20
In an email from Lixia on 29.05.2007 05:57:14, lixia@CS.UCLA.EDU it says :
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>
Splitting prefixes is a simple and effective means to achieve= =20 traffic 
engineering goals, and whoever needs to do it will do it= . I=20 believe a 
scalable solution essentially lies on the ability to=20 effectively (re)
aggregate prefixes.

my answer was:
...or, just the opposite as I believe, on a design that removes th= e=20 pressure for doing prefix aggregation totally.
 
Then silence.
 
More then ten years ago we worked in the PNNI-WG of the ATM Forum. Geor= g=20 Swallow had already introduced the "UPLINK". A border-to-border node link=20 between two peer groups was supposed to be representated by some uplink. Tha= t=20 uplink was subject to be aggregated to some induced uplink, eventually sever= al=20 times in some recursive manner, and finally supposed =B4to become part of a=20 "higher level horizontal link". The same applied to the neighboring side so=20= that=20 from either side the same border-to-border link had to wind up in the same=20 higher level horizontal link by either side.
 
I was against that link/upling aggregation:
I told the audience,  when we will adjourn the meeting, = we=20 only have to know at which city, which hotel and which ballroom the nex= t=20 meeting will take place, and every one is able to get there next time. Based= on=20 this thought the Aggregation Token was born, and the horrible topic of=20 aggregating links/uplinks was off the table.
 
The link/uplink aggregation would have caused, relatively, the same&nbs= p;=20 scalability problem that this community is about to fight.  So this is=20= just=20 another proof that there is no need to effectively (re) aggregate=20 prefixes.
 
Heiner
 
-------------------------------1181596172-- --===============1533750681== 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 --===============1533750681==-- From ram-bounces@iab.org Mon Jun 11 17: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 1HxrEq-0000lb-OH; Mon, 11 Jun 2007 17:15:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxrEp-0000lU-MS for ram@iab.org; Mon, 11 Jun 2007 17:15:47 -0400 Received: from imo-d05.mx.aol.com ([205.188.157.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxrEo-00055P-Ee for ram@iab.org; Mon, 11 Jun 2007 17:15:47 -0400 Received: from HeinerHummel@aol.com by imo-d05.mx.aol.com (mail_out_v38_r9.2.) id c.bba.1943470b (41810); Mon, 11 Jun 2007 17:15:37 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Mon, 11 Jun 2007 17:15:37 EDT Subject: Re: [RAM] revised draft proposed definitions To: tli@cisco.com, lear@cisco.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5014 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: rja@extremenetworks.com, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0992436251==" Errors-To: ram-bounces@iab.org --===============0992436251== Content-Type: multipart/alternative; boundary="-----------------------------1181596537" -------------------------------1181596537 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 11.06.2007 22:08:03 Westeurop=E4ische Normalzeit schreibt= =20 tli@cisco.com: Ok, but a locator does NOT denote reachability. (( Thus, a locator is a =20 string of bits that indicates a topological location.)) Tony Wrong, Tony. Deeply wrong. I cannot say more at this moment in time. =20 Heiner =20 -------------------------------1181596537 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 11.06.2007 22:08:03 Westeurop=E4ische Normalzeit sch= reibt=20 tli@cisco.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>
Ok,=20 but a locator does NOT denote reachability. (( Thus, a locator is a&n= bsp;=20
string of bits that indicates a topological=20 location.))

Tony
Wrong, Tony. Deeply wrong.
I cannot say more at this moment in time.
 
Heiner
-------------------------------1181596537-- --===============0992436251== 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 --===============0992436251==-- From ram-bounces@iab.org Tue Jun 12 04:23: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 1Hy1f2-0006hJ-3a; Tue, 12 Jun 2007 04:23:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1f1-0006hA-2f for ram@iab.org; Tue, 12 Jun 2007 04:23:31 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy1ez-0002tz-Oz for ram@iab.org; Tue, 12 Jun 2007 04:23:31 -0400 Received: by ug-out-1314.google.com with SMTP id m2so116468uge for ; Tue, 12 Jun 2007 01:23:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=kt7zYsV0ewvSAJG9d+3yAtSW/DZCI/aUNMMVIo4WdAf28DD9bGOR3nyom4tzMWSHeGonuSnm+PIqfD8BdKq/gVO+JUr2jhF5VWYNNPyjFor8b15REXLOf1epKMDvkfg2253mk4RRGxRSal1KeqA5aaaA7x6hytIVIS7XLMPMeRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=lckZ5/VLSm+gjsBcdWqXtrih0xxIjQHWW0vAQOcKufb7GLIv+35gjn6f3Jfabw7rLvJWRnFhEQb63RcArShvZ5sMkUrpOQbFgbMqHbBS+G9nxjiQap2mmAxLRTNOPfAGHPEka0gwU0jQo2iMbz5V1nVu41BIBip5/ROOffY3Z+c= Received: by 10.67.29.7 with SMTP id g7mr371914ugj.1181636606753; Tue, 12 Jun 2007 01:23:26 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id l40sm302064ugc.2007.06.12.01.23.25 (version=SSLv3 cipher=RC4-MD5); Tue, 12 Jun 2007 01:23:26 -0700 (PDT) Message-ID: <466E57FC.6040007@gmail.com> Date: Tue, 12 Jun 2007 10:23:24 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: rja@extremenetworks.com Subject: Re: [RAM] (no subject) 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: 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 ... >> One for E.164 (instead of DNS mapping a la enum) ? Etc. etc. > > I believe that it might also be possible to algorithmically > place an E.164 into an NSAP and then into an IPv6 address > using the special prefix that means an NSAP is in the low-order > bits of the IPv6 address. It isn't clear to me whether > this is explicitly documented at present. RFC 4048 obsoleted that possibility. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 12 04:33: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 1Hy1oh-00033a-OG; Tue, 12 Jun 2007 04:33:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1og-00033J-8K for ram@iab.org; Tue, 12 Jun 2007 04:33:30 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hy1od-0005YR-OJ for ram@iab.org; Tue, 12 Jun 2007 04:33:30 -0400 Received: by ug-out-1314.google.com with SMTP id m2so117974uge for ; Tue, 12 Jun 2007 01:33:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=k5Cjys8pqIjxve1QM0AYqe/gXTJD5kimaDxWllsq0QPJERgqJ6WkfV0B6QGJBFGOl4bpWm0DFak7eeTL7YySZU9Y6j7NxHb0963fTW/hsp9DY4Tn3b9C2bncT1yremIr0H1MMP/I13ZfOz0hQrOlIRY1KbqPaRTqZ2PiP9Yox38= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=DQWMtXcCr2n8JnunQ9rPQ8sCWaKtUZwX6H6pjVxHiRZO90FQjiAAJdttWjaQGpR2F3VNhMWy+nCW/51Do45ROJ/oiMETe+S/tL0j984wiijlzGDo82wt+MAkdrX4+aNQKhAU15B3cd2ubHVFRn8muEaTnd4d5/2SzqdEn7D3OFw= Received: by 10.67.118.8 with SMTP id v8mr372377ugm.1181637206595; Tue, 12 Jun 2007 01:33:26 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id p32sm298538ugc.2007.06.12.01.33.25 (version=SSLv3 cipher=RC4-MD5); Tue, 12 Jun 2007 01:33:26 -0700 (PDT) Message-ID: <466E5A53.9000505@gmail.com> Date: Tue, 12 Jun 2007 10:33:23 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [RAM] Re: revised draft proposed definitions References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> <20070611203028.GA13021@sources.org> In-Reply-To: <20070611203028.GA13021@sources.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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-06-11 22:30, Stephane Bortzmeyer wrote: ... >> Locator: An object that is used only for forwarding packets >> or determining location, never for identification. > > I was not able to find an example of a global locator, in the current > IETF standards. Does anyone have an existing example? I would have thought that a global-scope IPv6 address under a PA prefix is certainly intended to be a global locator. Before RFC 1597, I understood all IPv4 addresses to be intended to be global locators. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 12 04:38: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 1Hy1tN-0007HJ-FF; Tue, 12 Jun 2007 04:38:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1tM-0007HA-9y for ram@iab.org; Tue, 12 Jun 2007 04:38:20 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy1tL-0001q6-Tg for ram@iab.org; Tue, 12 Jun 2007 04:38:20 -0400 Received: by ug-out-1314.google.com with SMTP id m2so118668uge for ; Tue, 12 Jun 2007 01:38:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Hezz4Q6vqRRzfHYts3fkl4qJ7ihYe5lMKXPauImTDhPF/BURi1dgSdH1QAQY7IK0v7R2cNuPiJqjYRbhhfNJoFqX09J81nOfbhxwoQksxjQSBEVCWBohbpjl2v6w9zWmdNnQKg8r18h/yxILx45gdxCj98rNmj9nWx+c/4zOzX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=X2d52ydDoL/ANQmL/E+2x0HFqbxQDdeyGLC/1KmjS3szPyGOe6kKKOcvT1yHft0LJT22RCdZ/wL3TAcHddFXT7EuEJXzHO3+dfWKqsGpeZUVTNe44zG0sfCFGyPkpVCsnjPkITxk5w9n5Kqkw8qQ01eauaVYFa5TTnezq5zRBRY= Received: by 10.82.178.11 with SMTP id a11mr12750993buf.1181637499059; Tue, 12 Jun 2007 01:38:19 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id h7sm688863nfh.2007.06.12.01.38.18 (version=SSLv3 cipher=RC4-MD5); Tue, 12 Jun 2007 01:38:18 -0700 (PDT) Message-ID: <466E5B78.4090501@gmail.com> Date: Tue, 12 Jun 2007 10:38:16 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] revised draft proposed definitions References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> <466D69FC.3010003@cisco.com> <715690CE-8527-4123-9A09-101FC7EDF5EC@cisco.com> In-Reply-To: <715690CE-8527-4123-9A09-101FC7EDF5EC@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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-06-11 22:05, Tony Li wrote: ... > That still fails the test of describing what things are. What we want > is to take a constructive approach: > > An identifier is an element of a namespace. There is a 1:1 mapping > between the namespace and the entities being enumerated. > > >>> Locator: An object that is used only for forwarding packets >>> or determining location, never for identification. >> >> Same comment only in reverse ;-) "A locator denotes presence at a >> specific point in the network. When one's location within a network >> changes, one locator changes". > > > Ok, but a locator does NOT denote reachability. Thus, a locator is a > string of bits that indicates a topological location. It seems relevant to paste in the definitions I use in draft-carpenter-idloc-map-cons. I strongly agree with Tony that we must relate the notion of ID to a specific namespace. We may differ slightly on Loc: Locator: A binary quantity (not necessarily an IP Address) that can be used by a routing or forwarding device to decide where to send a packet. Identifier: A binary quantity (not necessarily an IP Address) that can be used by a Stack "A" to uniquely identify another Stack "B" both for bilateral communication and for informing a third Stack "C" that it should communicate with Stack "B". (Note that there is an assumption in this definition that a Stack is the entity we require to identify; in this era of virtualized servers with failover capabilities, and of mobile clients, this seems to be a reasonable assumption.) Namespace: a set of natural numbers, each of which is referred to as a name. Since it is a set, by definition each name is unique and thus the namespace is unambiguous. Locators and Identifiers must belong to specific namespaces. Namespace Context: the context within which a given namespace retains its uniqueness property. (For example, the Namespace Context of the Namespace created by [RFC1918] is a single Internet site.) Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 12 06:58: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 1Hy44y-0003ns-5b; Tue, 12 Jun 2007 06:58:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy44x-0003nn-Gi for ram@iab.org; Tue, 12 Jun 2007 06:58:27 -0400 Received: from xmail09.myhosting.com ([168.144.250.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy44w-00086T-7h for ram@iab.org; Tue, 12 Jun 2007 06:58:27 -0400 Received: (qmail 16486 invoked from network); 12 Jun 2007 10:58:25 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Jun 2007 10:58:25 -0000 Message-ID: <466E7C4A.3000002@cisco.com> Date: Tue, 12 Jun 2007 06:58:18 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] revised draft proposed definitions References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> <466D69FC.3010003@cisco.com> <715690CE-8527-4123-9A09-101FC7EDF5EC@cisco.com> In-Reply-To: <715690CE-8527-4123-9A09-101FC7EDF5EC@cisco.com> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 > Ok, but a locator does NOT denote reachability. Thus, a locator is a > string of bits that indicates a topological location. I think we should, perhaps, leave reachability out? It seems like both a locator and and id indicate some element of reachability (?). IE, if you have a locator, and no ID, then there is nothing to reach, but if you have an id, and no locator, there is no place to reach it at. I don't see an easy way to separate these two concepts? :-) 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 iD8DBQFGbnxKER27sUhU9OQRAs2PAJwJbxwsG3EzaXJMnNAnxxmwM6FzQACgpp4v 0Ny5AI4HZXIpi6v0sCupqiM= =gwoh -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 12 08:14: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 1Hy5Gm-0001A7-EZ; Tue, 12 Jun 2007 08:14:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5Gl-00019v-8P for ram@iab.org; Tue, 12 Jun 2007 08:14:43 -0400 Received: from eastrmmtao104.cox.net ([68.230.240.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy5Gj-00076d-UU for ram@iab.org; Tue, 12 Jun 2007 08:14:43 -0400 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070612121441.VXO8179.eastrmmtao104.cox.net@eastrmimpo02.cox.net> for ; Tue, 12 Jun 2007 08:14:41 -0400 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo02.cox.net with bizsmtp id AcEh1X00B0pnMhQ0000000; Tue, 12 Jun 2007 08:14:41 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <466E7C4A.3000002@cisco.com> References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> <466D69FC.3010003@cisco.com> <715690CE-8527-4123-9A09-101FC7EDF5EC@cisco.com> <466E7C4A.3000002@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10DD5D2F-6694-4097-BA8C-B7EC1E350A66@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] revised draft proposed definitions Date: Tue, 12 Jun 2007 08:14:39 -0400 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) 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 12 Jun 2007, at 06:58, Russ White wrote: > Earlier, someone else said: >> Ok, but a locator does NOT denote reachability. Thus, >> a locator is a string of bits that indicates a topological >> location. > > I think we should, perhaps, leave reachability out? It seems > like both a locator and and id indicate some element of > reachability (?). Neither indicates reachability. > IE, if you have a locator, and no ID, then there is nothing to reach, The locator might name a subnetwork, for example. That subnetwork might well be reachable or might not be reachable. > but if you have an id, and no locator, there is no place to reach > it at. Then one can name the node, but one doesn't know where the node is located, (even if it happens to be reachable at that instant in time at some specific location). The original quote at top is correct. Having a locator does not mean that there is a working forwarding path between one's current location and the location named by that original loocator. Purely as an example, an ACL somewhere along the path might cause one's packets towards that location to be dropped. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 12 08:39: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 1Hy5ey-0005FR-7r; Tue, 12 Jun 2007 08:39:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5ex-0005ED-6t for ram@iab.org; Tue, 12 Jun 2007 08:39:43 -0400 Received: from montage2.altserver.com ([72.34.52.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy5dI-0004ae-H7 for ram@iab.org; Tue, 12 Jun 2007 08:38:00 -0400 Received: from eurolab.net2.nerim.net ([213.41.175.161]:2460 helo=asus.jefsey.com) by montage2.altserver.com with esmtp (Exim 4.63) (envelope-from ) id 1Hy5dG-000427-QG; Tue, 12 Jun 2007 05:37:59 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Jun 2007 12:57:45 +0200 To: Brian E Carpenter From: JFC Morfin Subject: Re: [RAM] revised draft proposed definitions In-Reply-To: <466E5B78.4090501@gmail.com> References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> <466D69FC.3010003@cisco.com> <715690CE-8527-4123-9A09-101FC7EDF5EC@cisco.com> <466E5B78.4090501@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Pass-two: yes X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage2.altserver.com X-AntiAbuse: Original Domain - iab.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) 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 Message-Id: Brian, Tony said "a string of bits", this seems adequate. I am not sure that you want an address to always be binary. I start working on multilingual semantic addressing support in relation with the cctags (they actually root national linguistic relational spaces taxonomies, as in a some more granular way the langtags do, from a linguistic POV). These addresses are not binary. They are not used to route through the network (at least now), but they can locally to the destination. If you consider HTTP.1.1 it supports binary (network) and non-binary (virtual host) addresses collapsing naming and addressing space at local level into a single space. This is something you may not wish, but this is something possible and being used. Also, just remember that multi-level naming (one can use for multilevel semantic addressing and multilevel IP addressing, must be self-similar (another way to say it must scale)). However, "self-similar" makes clearer that this can be up/down scalarity. And therefore, since the current binary/semantic syntax is something being used, which works correctly, and will therefore be used, so you must stay compatible with it. jfcm On 10:38 12/06/2007, Brian E Carpenter said: >Content-Transfer-Encoding: 7bit > >On 2007-06-11 22:05, Tony Li wrote: >... >>That still fails the test of describing what things are. What we >>want is to take a constructive approach: >>An identifier is an element of a namespace. There is a 1:1 mapping >>between the namespace and the entities being enumerated. >> >>>>Locator: An object that is used only for forwarding packets >>>> or determining location, never for identification. >>> >>>Same comment only in reverse ;-) "A locator denotes presence at a >>>specific point in the network. When one's location within a >>>network changes, one locator changes". >> >>Ok, but a locator does NOT denote reachability. Thus, a locator is >>a string of bits that indicates a topological location. > >It seems relevant to paste in the definitions I use in >draft-carpenter-idloc-map-cons. I strongly agree with Tony that >we must relate the notion of ID to a specific namespace. We may >differ slightly on Loc: > > Locator: A binary quantity (not necessarily an IP Address) that can > be used by a routing or forwarding device to decide where to send a > packet. > > Identifier: A binary quantity (not necessarily an IP Address) that > can be used by a Stack "A" to uniquely identify another Stack "B" > both for bilateral communication and for informing a third Stack "C" > that it should communicate with Stack "B". (Note that there is an > assumption in this definition that a Stack is the entity we require > to identify; in this era of virtualized servers with failover > capabilities, and of mobile clients, this seems to be a reasonable > assumption.) > > Namespace: a set of natural numbers, each of which is referred to as > a name. Since it is a set, by definition each name is unique and > thus the namespace is unambiguous. Locators and Identifiers must > belong to specific namespaces. > > Namespace Context: the context within which a given namespace retains > its uniqueness property. (For example, the Namespace Context of the > Namespace created by [RFC1918] is a single Internet site.) > > 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 Jun 12 08:59: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 1Hy5yV-0007DC-8G; Tue, 12 Jun 2007 08:59:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5yU-0007D6-On for ram@iab.org; Tue, 12 Jun 2007 08:59:54 -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 1Hy5yU-0002C8-Au for ram@iab.org; Tue, 12 Jun 2007 08:59:54 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 12 Jun 2007 05:59:53 -0700 X-IronPort-AV: i="4.16,411,1175497200"; d="scan'208"; a="2651976:sNHT20838426" 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 l5CCxr95032150; Tue, 12 Jun 2007 05:59:53 -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 l5CCxc24004976; Tue, 12 Jun 2007 12:59: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); Tue, 12 Jun 2007 05:59:45 -0700 Received: from [10.21.66.92] ([10.21.66.92]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 05:59:44 -0700 Message-ID: <466E989E.6050704@employees.org> Date: Tue, 12 Jun 2007 08:59:10 -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.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [RAM] Re: revised draft proposed definitions References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> <20070611203028.GA13021@sources.org> In-Reply-To: <20070611203028.GA13021@sources.org> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2007 12:59:44.0821 (UTC) FILETIME=[8C88A650:01C7ACF1] Authentication-Results: sj-dkim-2; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 06/11/2007 16:30 PM, Stephane Bortzmeyer allegedly wrote: >> Locator: An object that is used only for forwarding packets >> or determining location, never for identification. > > I was not able to find an example of a global locator, in the current > IETF standards. Does anyone have an existing example? If your objection is because of NAT, then I have to agree that you cannot *know* if a locator is global in scope, although things work better if they are. >> Scoped Locator: A locator that has non-global scope. Note that >> a scoped locator only has location semantics, >> never identification semantics. > > A MPLS label is a scoped locator. Am I right? Connection-oriented packet switching is a very different sort of beast. I think we should restrict this discussion to connectionless. What a label does is it selects how the packet should be processed next. >> Identifier/Locator split: A class of network protocol that >> has no addresses, and only has (pure) identifiers >> and (pure) locators. Proposals in the GSE/8+8 >> class of solution might be examples of this, >> depending on the details of the proposal. > > HIP too, no? Yes, HITs are identifiers (not identities :-p) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 12 09:07: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 1Hy65g-0004jH-4U; Tue, 12 Jun 2007 09:07:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy65f-0004jC-5t for ram@iab.org; Tue, 12 Jun 2007 09:07:19 -0400 Received: from xmail03.myhosting.com ([168.144.250.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy65d-00043c-S2 for ram@iab.org; Tue, 12 Jun 2007 09:07:19 -0400 Received: (qmail 29923 invoked from network); 12 Jun 2007 13:07:17 -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 ESMTPA for ; 12 Jun 2007 13:07:17 -0000 Message-ID: <466E9A7D.5010500@cisco.com> Date: Tue, 12 Jun 2007 09:07:09 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] revised draft proposed definitions References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> <466D69FC.3010003@cisco.com> <715690CE-8527-4123-9A09-101FC7EDF5EC@cisco.com> <466E7C4A.3000002@cisco.com> <10DD5D2F-6694-4097-BA8C-B7EC1E350A66@extremenetworks.com> In-Reply-To: <10DD5D2F-6694-4097-BA8C-B7EC1E350A66@extremenetworks.com> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 >>> Ok, but a locator does NOT denote reachability. Thus, >>> a locator is a string of bits that indicates a topological >>> location. >> >> I think we should, perhaps, leave reachability out? It seems >> like both a locator and and id indicate some element of reachability (?). > > Neither indicates reachability. > The original quote at top is correct. Having a locator does not > mean that there is a working forwarding path between one's > current location and the location named by that original loocator. > Purely as an example, an ACL somewhere along the path might > cause one's packets towards that location to be dropped. So, your basic argument is that because you may, at times, have a locator and an id, and the device might still not be reachable, you can never say locators or id's carry reachability information? That seems to be stretching it a bit--if some of b is not contained in a, then none of b must be contained in a. If a locator/id pair never contains reachability, then reachability is a mythological creature, and the Internet fails. The exception does not rule out the general case. An ID is useless for reaching a device without a locator, hence a locator must be present to reach the device, hence a locator carries some type of reachability information. If a locator didn't carry reachability information, it wouldn't be required to reach a device. At the same time, locator is useless for reaching a device without an ID. Hence, and ID must be present to reach a device. If an ID didn't carry any sort of reachability information, it wouldn't be required to reach the device, hence an ID must carry some form of reachability information. You may redefine "reachability," so there are two different types of this beast, but if you can't reach something without a specific piece of information, that specific piece of information carries reachability as part of it's meaning. Unless, of course.... You're going to propose a third, and completely different thing, which doesn't exist in the routing context at all today, a "reachability advertisement." This would have a "reachable through this path" bit of some type, which says that not only does the device exist, it is also reachable along a specific path. Since IP networks are hop by hop, and not session oriented, the idea of a "path," itself, within IP, is rather ambiguous, and hence, such and advertisement would be problematic, at best. :-) 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 iD8DBQFGbpp9ER27sUhU9OQRAgUjAJ40fBPkOJPnE+hb0w8S7ZXu7jzVQQCfV65V OZpOSuJsaOF+apG1HU5VpGU= =8teH -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 12 09:44: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 1Hy6fq-0003z7-0U; Tue, 12 Jun 2007 09:44:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy6fp-0003yz-8l for ram@iab.org; Tue, 12 Jun 2007 09:44:41 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy6fn-0004EJ-Vm for ram@iab.org; Tue, 12 Jun 2007 09:44:41 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id E03A21C0107; Tue, 12 Jun 2007 15:44:37 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id DAB221C0103; Tue, 12 Jun 2007 15:44:35 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id D743B58EBE7; Tue, 12 Jun 2007 15:44:35 +0200 (CEST) Date: Tue, 12 Jun 2007 15:44:35 +0200 From: Stephane Bortzmeyer To: Scott W Brim Message-ID: <20070612134435.GA27174@nic.fr> References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> <20070611203028.GA13021@sources.org> <466E989E.6050704@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <466E989E.6050704@employees.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: 52e1467c2184c31006318542db5614d5 Cc: RJ Atkinson , ram@iab.org Subject: [RAM] Re: revised draft proposed definitions X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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, Jun 12, 2007 at 08:59:10AM -0400, Scott W Brim wrote a message of 31 lines which said: > > I was not able to find an example of a global locator, in the > > current IETF standards. Does anyone have an existing example? > > If your objection is because of NAT, No, it is independant of NAT. I said that, currently, it seems that global "pure" locators (those that are never used for identification) do not exist in the IETF world. (And, even outside of the IETF realm, I have trouble naming even one. Street addresses? Longitude/latitude coordinates for your favorite ICBM?) > > A MPLS label is a scoped locator. Am I right? > > Connection-oriented packet switching is a very different sort of > beast. I think we should restrict this discussion to > connectionless. You define MPLS as connection-oriented? This surprises me. > >> Identifier/Locator split: A class of network protocol that > >> has no addresses, and only has (pure) identifiers > >> and (pure) locators. Proposals in the GSE/8+8 > >> class of solution might be examples of this, > >> depending on the details of the proposal. > > > > HIP too, no? > > Yes, HITs are identifiers (not identities :-p) The question is not about HITs but about HIP (the protocol). Under the above definition, is HIP a good example of a "Identifier/Locator split"? (I would say yes.) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 12 10:21: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 1Hy7Fa-0005cM-Qs; Tue, 12 Jun 2007 10:21:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7Fa-0005cG-0o for ram@iab.org; Tue, 12 Jun 2007 10:21:38 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy7FZ-0006lk-Pa for ram@iab.org; Tue, 12 Jun 2007 10:21:37 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0D73087328; Tue, 12 Jun 2007 10:21:37 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] revised draft proposed definitions Message-Id: <20070612142137.0D73087328@mercury.lcs.mit.edu> Date: Tue, 12 Jun 2007 10:21:37 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 >> Ok, but a locator does NOT denote reachability. Thus, a locator is a >> string of bits that indicates a topological location. > I think we should, perhaps, leave reachability out? It seems like both > a locator and and id indicate some element of reachability (?). Russ, reachability is a very different kind of thing, more an operational property (i.e. a property of a name in particular circumstances in an functioning system) , rather than a semantic one (i.e. an inherent property of a particular name). To give some examples, let's use 'IPvN address', which has relatively well understood properties (since differing definitions are a real problem in this discussion), but has the same "indicates a topological location" property as "locator". Assume I have a host H at a site S, which is connected to the rest of the Internet via router R; H, S and R all have an IPvN addresses. For the first example, if the cable which connects H to the rest of the world is unplugged, it still has a correct and authorized IPvN address, but it is no longer reachable (from anywhere). For a slightly more complex example, consider the situation, but this time the link connecting R and the rest of the world is unplugged. In this case, H is still reachable from hosts inside S, but not from the rest of the world. So we can see that "reachability" is not a property of an address, but a property of a tuple, (source, reachable_destination). Moreover, depending on the actual network connectivity, and the contents of the routing tables, reachability of a particular (source, reachable_destination) tuple can vary over time. So, yes, because reachabilty is an operational property, and not an inherent semantic property, it definitely should be placed in a separate category (although any definitions document might useful explain the above). Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 12 10:54: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 1Hy7kt-0005tg-94; Tue, 12 Jun 2007 10:53:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7ks-0005tY-JS for ram@iab.org; Tue, 12 Jun 2007 10:53:58 -0400 Received: from xmail06.myhosting.com ([168.144.250.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy7kr-0005de-AO for ram@iab.org; Tue, 12 Jun 2007 10:53:58 -0400 Received: (qmail 18217 invoked from network); 12 Jun 2007 14:53:56 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Jun 2007 14:53:55 -0000 Message-ID: <466EB37C.50207@cisco.com> Date: Tue, 12 Jun 2007 10:53:48 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [RAM] revised draft proposed definitions References: <20070612142137.0D73087328@mercury.lcs.mit.edu> In-Reply-To: <20070612142137.0D73087328@mercury.lcs.mit.edu> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > So we can see that "reachability" is not a property of an address, but a > property of a tuple, (source, reachable_destination). Moreover, depending on > the actual network connectivity, and the contents of the routing tables, > reachability of a particular (source, reachable_destination) tuple can vary > over time. Once you go to a locator/id split, it seems like the tuple would need to be expanded to: {source, locator, id}. You could count "reachability" as a "flag" for any specific tuple, but you can't set the flag without the tuple in place. :-) > So, yes, because reachabilty is an operational property, and not an inherent > semantic property, it definitely should be placed in a separate category > (although any definitions document might useful explain the above). It might be clearer to state that while the locator and id are required to provide reachability, reachability is not always implied because you have the full tuple. The problem is, I think, that reachability is not an object, nor does it describe the object. It is a state, rather than a descriptor, if you want to define it that way. The problem is that the state isn't valid unless you have the descriptors, so it all depends on the definition you're using. Any definitions document should be clear on this, I think. BTW, I do think the locator and ID are both required for the tuple. With DNS, today, we have reachability without IDs, but I think this causes problems for policy and security. It's much cleaner to require both before the reachability "flag" can be set, or the reachability state to be positive, or however you want to say it. :-) 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 iD8DBQFGbrN8ER27sUhU9OQRAm3SAKCcDcDoy9+4ajxqNXSZ50bcPhlJmACfUJKo GO1ouNB+XhVXRARRTtSphs8= =EtmA -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 12 14:22: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 1HyB0F-0007u7-I9; Tue, 12 Jun 2007 14:22:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyB0E-0007tX-A3 for ram@iab.org; Tue, 12 Jun 2007 14:22:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyB0B-0001kV-24 for ram@iab.org; Tue, 12 Jun 2007 14:22:02 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 12 Jun 2007 14:21:58 -0400 X-IronPort-AV: i="4.16,412,1175486400"; d="scan'208"; a="62565078:sNHT45788714" 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 l5CILwK8019068; Tue, 12 Jun 2007 14:21:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5CILe63014367; Tue, 12 Jun 2007 18:21:54 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 14:21:40 -0400 Received: from [192.168.0.101] ([10.82.217.158]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 14:21:39 -0400 In-Reply-To: <466E5B78.4090501@gmail.com> References: <808E6500-97B4-4107-8A2F-36BC913BE196@extremenetworks.com> <466D69FC.3010003@cisco.com> <715690CE-8527-4123-9A09-101FC7EDF5EC@cisco.com> <466E5B78.4090501@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <538E4FBC-D624-4221-945C-7D1BACBB481A@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] revised draft proposed definitions Date: Tue, 12 Jun 2007 11:21:35 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jun 2007 18:21:40.0015 (UTC) FILETIME=[85495BF0:01C7AD1E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=976; t=1181672518; x=1182536518; c=relaxed/simple; s=rtpdkim2001; 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]=20revised=20draft=20proposed=20definitions |Sender:=20 |To:=20Brian=20E=20Carpenter=20; bh=FP93absRVoagPUdXY1mouseF18aiFuV4FpeCLA9PfmA=; b=f6pvOnX/7GucMMoVHez5Y7CkLr8+ERbH3zWJ4U0VXSLo+z+H5oiXqXgbJ5gmbBGPkN6o6ksO D7d1DG+mTdYhvaCKvrmSaGYzmbRFZOC2mh8JOLBTV2juIKOb+1qsVhEY; Authentication-Results: rtp-dkim-2; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Identifier: A binary quantity (not necessarily an IP Address) that > can be used by a Stack "A" to uniquely identify another Stack "B" > both for bilateral communication and for informing a third Stack > "C" > that it should communicate with Stack "B". (Note that there is an > assumption in this definition that a Stack is the entity we require > to identify; in this era of virtualized servers with failover > capabilities, and of mobile clients, this seems to be a reasonable > assumption.) Brian, I have a minor quibble with this, in that it's really defining a stack identifier, not a generic identifier. Any given proposal may choose to have identifiers at many levels (e.g. transport connection identifiers, interface identifiers, host identifiers, etc.) and the definition needs to either be sufficiently abstract so as to encompass all of these, or the term being defined needs to be qualified. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 12 17:06:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDZE-0004Kg-WE; Tue, 12 Jun 2007 17:06:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDZD-0004KZ-BP for ram@iab.org; Tue, 12 Jun 2007 17:06:19 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDZD-0004TT-4N for ram@iab.org; Tue, 12 Jun 2007 17:06:19 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A88ED86AE4; Tue, 12 Jun 2007 17:06:18 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] some draft proposed definitions Message-Id: <20070612210618.A88ED86AE4@mercury.lcs.mit.edu> Date: Tue, 12 Jun 2007 17:06:18 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 > Here is a draft proposal for terminology ... This is a starting point, > not an all-inclusive list. After thinking about this for a while, I still think the best way to proceed is to identify axes of characteristics or attributes of potential names (as I suggested towards the end of my message yesterday), rather than the definition of particular terms, because I'm not sure we're going to get agreement on definitions. In part, that's because i) we're not trying to name all possible N-tuple (for N different axes) choice-sets along these axes - many of which probably aren't useful - but only the 'desirable' or 'interesting' ones, and people differ on which choice-sets are preferable (e.g. 'should the topology-sensitive names name interfaces or hosts'), and ii) allied to this, there are a limited number of words being tussled over. Also, my sense is that discussing what the possible axes are is more likely to be useful, because I think it will lead people to think more clearly about the underlying fundamentals. So, let me try and list the axes (and I'll then comment on your proposed definitions in a separate message). Here's my list of axes of characteristics or attributes of potential names, with the potential values for each: - Level: internetwork/transport - Object-named: physical-network (aka subnet)/interface/host-'endpoint'-stack - Locational: non-locational/network-topological/geographical - Uniqueness: globally-unique/locally-unique (within some scope)/non-unique - Directorizable: directorized/non-directorized - Ubiquity: in-all-packets/not-in-all-packets - Forwarding-tag: looked-at-by-switches/not-looked-at What others are there? Note that we can define useful terms without necessarily making picks along all these axes, but we might then need further qualifers when using one of these terms before it would clearly refer to one specific possibility. For example, if we define 'locator' without specifying one particular choice from the 'object-named' axis, we could then further refer to 'subnet locator' (your definition of 'locator'), 'interface locator' (my definition of 'locator'), or 'host locator' (IPv6 address definition). Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 12 17:19: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 1HyDm6-0000X3-Oh; Tue, 12 Jun 2007 17:19:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDm6-0000Vh-6F for ram@iab.org; Tue, 12 Jun 2007 17:19:38 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDm2-0001Hw-VD for ram@iab.org; Tue, 12 Jun 2007 17:19:38 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C78DD86AE4; Tue, 12 Jun 2007 17:19:34 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] some draft proposed definitions Message-Id: <20070612211934.C78DD86AE4@mercury.lcs.mit.edu> Date: Tue, 12 Jun 2007 17:19:34 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 > Here is a draft proposal for terminology ... This is a starting point, > not an all-inclusive list. Now for a few comments on your proposed definition > Identifier: An object that is used only for identification, > never for forwarding packets or determining location. A couple of problems with this one. First, the term "identifier" is a generic term, sort of equivalent to "name", and I think trying to restrict its meaning in any way is bound to cause confusion. Second, the term "object" is generally used to refer to the entities or instances that names are bound to; you probably want to use the term 'name' instead. However, I do agree it's useful to have the concept of a name whose only function is to indentify things, not say anything about where they are, or anything else. But I think we need a different word/phrase.. > Locator: An object that is used only for forwarding packets > or determining location, never for identification. There have been designs in which interfaces were named at the internet level with locators, and those locators were the only names those entities had. As such, those locators identified (in the generic sense) those interfaces. Of course, they did not 'identify' them (in the sense of 'identifier' above). Which shows the problem (above) with the term 'identifier'. (Also, "object" again.) > Address: An object that with mixed semantics, where it is > sometimes used for identity and sometimes used > for packet forwarding. Not only do the uses differ, but also the levels at which they are used, what they name, etc. E.g. IPvN addresses are used as locators at the internetwork level, and as identifiers at transport level. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jun 13 03: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 1HyNIi-0005Dp-0u; Wed, 13 Jun 2007 03:29:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyNIg-0005DW-9R for ram@iab.org; Wed, 13 Jun 2007 03:29:54 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyNIf-0005pc-RY for ram@iab.org; Wed, 13 Jun 2007 03:29:54 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 954F9212E84; Wed, 13 Jun 2007 10:29:52 +0300 (EEST) Received: from [127.0.0.1] (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 1A0E7212D85; Wed, 13 Jun 2007 10:29:52 +0300 (EEST) Message-ID: <466F8498.6070807@ericsson.com> Date: Wed, 13 Jun 2007 08:46:00 +0300 From: =?ISO-8859-1?Q?Mikko_S=E4rel=E4?= User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Scott W Brim Subject: Re: [RAM] some draft proposed definitions References: <9027C973-70C4-437A-9182-986063D7C7A8@extremenetworks.com> <20070611133959.1A7807DC9@bender.tigertech.net> <466D7B18.4010305@employees.org> In-Reply-To: <466D7B18.4010305@employees.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: 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 Here's my take on some of the definitions. Identifier: An element of a name space that persistently and uniquely identifies an entity, e.g. independent of the location of the entity. Locator: A string that indicates a particular point in the network topology. Identification: A means that an entity uses for identifying another entity, e.g. TCP uses a Locator (and port number) to identify the other end point. Address: A locator that is used for identification purposes. Note that identifiers can be used for forwarding data (e.g. ad hoc network routing protocols typically work with identifiers that have no topological meaning) and locators can be used for identification purposes (as TCP and UDP do). To me the question seems to be whether the naming should be based on the usage of an object, or by the purpose for which it was created. In the first case, you can say that if somebody uses a locator for identification purposes, then it is also an identifier. In the latter case, you would name the object based on its primary purpose (i.e. an IP address would be a locator used for identification purposes and not an identifier). If one does go for the former approach, then we will need to have separate definitions for persistent and non-persistent identifiers and possibly others, whenever somebody decides to use a new class of objects for identification. Similarly, if we define a locator based on the idea that it is used for forwarding, we will have to accept that we will have topologically non-meaningful locators, i.e. in ad hoc networks it is common to use flat identifier space for routing. And then we will need to define topologically meaningful locator and topologically non-meaningful locator separately. I think this approach is doomed to unnecessary complexity. Instead, I would go for the latter approach, and name objects based on their qualities and then denote the usage separately (i.e. IP address is a locator used for identification rather than an identifier). -Mikko _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jun 13 10:27: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 1HyTod-00083M-6U; Wed, 13 Jun 2007 10:27:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyToc-000838-5y for ram@iab.org; Wed, 13 Jun 2007 10:27:18 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyToa-0006v7-SX for ram@iab.org; Wed, 13 Jun 2007 10:27:18 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Jun 2007 16:27:13 +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 l5DERBUa013763 for ; Wed, 13 Jun 2007 16:27:11 +0200 Received: from dhcp-wdata-vlan18-22-227.cisco.com (dhcp-wdata-vlan18-22-227.cisco.com [144.254.22.227]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5DER7DR003247 for ; Wed, 13 Jun 2007 14:27:11 GMT Message-ID: <466FFEB8.9080701@cisco.com> Date: Wed, 13 Jun 2007 16:27:04 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: ram@iab.org 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=634; t=1181744832; x=1182608832; 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:=20draft-lear-lisp-nerd-01 |Sender:=20; bh=+Yzqfkmfg3YR3PsEUoK3VLYOCTOoki1G6Z20Is4lamk=; b=WNJxJVKu00uKd0A5b5CcJPmF+FxNK6N7SNKzmphza6izoqxNC5DJzP1mvBjaiAhVizFkwNHp 90s3HbmQ2Isjg54XGTEYcGsKLiqft4KdS+0OlGdDZBqqUsdGlIhbI4zz; 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: cf4fa59384e76e63313391b70cd0dd25 Subject: [RAM] draft-lear-lisp-nerd-01 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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've put together an internet draft that talks about a push-based distribution method for LISP. I call it NERD (Not-so-novel EID-RLOC Database). -00 has a few confusing editorial errors in it. -01 should be in the repository sometime today. If you've enjoyed LISP, you'll be amused (if nothing else) by NERD. It is my expectation, by the way, that other mapping approaches, some from Cisco, will be proposed. Just a reminder that this is experimental stuff. Heck, I still need to clean up a packet format for the proposed database signature (right now it's a hodge podge). Comments welcome, Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 04:51: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 1Hyl2g-000771-GZ; Thu, 14 Jun 2007 04:50:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyl2f-00074m-Nu for ram@iab.org; Thu, 14 Jun 2007 04:50:57 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyl2e-0005F4-Em for ram@iab.org; Thu, 14 Jun 2007 04:50:57 -0400 Received: by ug-out-1314.google.com with SMTP id m2so657012uge for ; Thu, 14 Jun 2007 01:50:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=Nx/GUGRF71h1Q/+4ATy30Xh8MTdcPeEgn2MLAmTs/9JMyVeoBxj8uU4MOZ+J1+1YaDIe5+rjmuum7HrducicwEA3HIl0VVz23JwbpiFDGVLShy7FuYUmswihCKnlFiHIsf9QYBG5oJgOM/Xm6v3rpT0Ow5jQddW4pXfyetszdlQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=UbbHK5nSnDUHsv8CcPzokbXPTB9Gj2cWTClOAmRBcQBw4IKJLzgrU2xrLCsGEVveNUyxAsn8zELjdNKkNkravJ7saMJrNIHMIWQt3K9NaOz6t5ll5wBqEiUfUwPn3vwu11kIWLEYPf54joZuBhKk4Fm540CQkLRmoTtm6/2ftCk= Received: by 10.67.26.6 with SMTP id d6mr1897774ugj.1181811055746; Thu, 14 Jun 2007 01:50:55 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id g30sm4263762ugd.2007.06.14.01.50.53 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Jun 2007 01:50:54 -0700 (PDT) Message-ID: <4671016C.7090200@gmail.com> Date: Thu, 14 Jun 2007 10:50:52 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [RAM] Ramblings about "locator" X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 was thinking about why we're having trouble being crisp about "locator". Maybe part of it is that in some contexts, as Noel hinted, a locator is loaded with topological significance. If the network topology in a given region is a strict binary hierarchy, then the locator may be very tightly mapped to the topology (and is in effect a route). But in other regions of the network where the topology is an arbitrary graph, the same locator has no mapping to topology and needs to be bound to a route by a routing protocol. Another thought is that on a classical broadcast Ethernet, an Ethernet address is a locator, but a rather strange one in that nobody except the receiver knows where the located interface is. But the same Ethernet address on a switched Ethernet or in a spanning tree becomes much more like a network-level locator; it's mapped to topology by the switching or bridging mechanism. Maybe the essential point is that a locator can at least in principle be mapped to topology and an identifier can't. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 07:38: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 1Hynec-0006rx-Jq; Thu, 14 Jun 2007 07:38:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyneb-0006ro-Bf for ram@iab.org; Thu, 14 Jun 2007 07:38:17 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyneZ-0002sF-TS for ram@iab.org; Thu, 14 Jun 2007 07:38:17 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5EBbr37005855; Thu, 14 Jun 2007 14:38:13 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 14:38:04 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 14:38:04 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Ramblings about "locator" Date: Thu, 14 Jun 2007 14:38:03 +0300 Message-ID: In-Reply-To: <4671016C.7090200@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Ramblings about "locator" Thread-Index: AceuYSfXVVsf4PG+TQOppn0Za6/pXQAFWpGg References: <4671016C.7090200@gmail.com> From: To: , X-OriginalArrivalTime: 14 Jun 2007 11:38:04.0633 (UTC) FILETIME=[789ECC90:01C7AE78] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Brian E Carpenter wrote: >Maybe the essential point is that a locator can at least in=20 >principle be mapped to topology and an identifier can't. > IMO an ethernet "address" is an identifier. It uniquely identifies the Ethernet interface in the (name)space of all existing and future ethernet interfaces. A locator has some built in topological significance. It is conceivable that any identifier could be used for a routing and forwarding in a flat architecture, where there is no aggregation based on topology. If we had no aggregation in IP addressing, i.e. if we had IP addresses free of any topological significance (like the ethernet addresses), then we would not have the current ID/loc split issue either. In a such system we could do all the multi-homing, mobility, etc. we wanted with more elaborate routing protocols. To summarise the point in the ID/loc split discussion is not about whether something can be used for routing and/or forwarding or not. The issue is with the built-in topological significance that limits the use of such "locator" to a somehow restricted topology, when we would want to have somehow different topology (more dynamic, multi-homed, etc.) instead. So the issue is about having identifiers free of network topological significance. It is yet another discussion whether these identifiers could/should have semantics on some other axis, e.g. whether these identifiers should be somehow structured for organizational (=3Dadministration/"ownership") reasons. Regards, Jarno Rajahalme _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 08:47: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 1HyojE-0005NV-PB; Thu, 14 Jun 2007 08:47:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyojD-0005NK-SK for ram@iab.org; Thu, 14 Jun 2007 08:47:07 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyojC-0006zY-BY for ram@iab.org; Thu, 14 Jun 2007 08:47:07 -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 7171628; Thu, 14 Jun 2007 08:47:04 -0400 In-Reply-To: <4671016C.7090200@gmail.com> References: <4671016C.7090200@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2D7BD830-65B2-44B8-8E70-D6A1955CE540@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [RAM] Ramblings about "locator" Date: Thu, 14 Jun 2007 08:46:57 -0400 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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; On Jun 14, 2007, at 4:50 AM, Brian E Carpenter wrote: > I was thinking about why we're having trouble being crisp about > "locator". > > Maybe part of it is that in some contexts, as Noel hinted, a > locator is loaded with topological significance. If the > network topology in a given region is a strict binary > hierarchy, then the locator may be very tightly mapped > to the topology (and is in effect a route). But in other > regions of the network where the topology is an arbitrary > graph, the same locator has no mapping to topology and needs > to be bound to a route by a routing protocol. > > Another thought is that on a classical broadcast Ethernet, > an Ethernet address is a locator, but a rather strange one > in that nobody except the receiver knows where the located > interface is. But the same Ethernet address on a switched > Ethernet or in a spanning tree becomes much more > like a network-level locator; it's mapped to topology by > the switching or bridging mechanism. > > Maybe the essential point is that a locator can at least in > principle be mapped to topology and an identifier can't. > If in Ethernet what is essentially a random number (the MAC address) becomes a locator then maybe the distinction will never be crisp. Regards Marshall > 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 Thu Jun 14 09: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 1HypDR-0008RJ-W4; Thu, 14 Jun 2007 09:18:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HypDP-00088t-TP for ram@iab.org; Thu, 14 Jun 2007 09:18:19 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HypD8-00087z-1B for ram@iab.org; Thu, 14 Jun 2007 09:18:19 -0400 Received: by ug-out-1314.google.com with SMTP id m2so704912uge for ; Thu, 14 Jun 2007 06:18:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=kpOQ3gwLFjktycqxFeFopASqkOUSZGgeByXUpzrxVg9VqUXDd9e9m6gZW80TGSOWx8SmT45iGA70FfCy89eqp52zKKl/z1OqP5X4XAe+k+bnTMluuhP2wfdLbGIa4WJIMTN33zIwAjwFLZSJLnXnxyFnuRSc/dAB90sNsA8881g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=jaUg61eMwuMVtKNuf97did4H9HLOqMXjzme8I5vGLWVMPDNNeVLsrQly7ZTGGzniDx/N+IMBcvRtOiaxrTLB5HzVOU+L6QQlDGJjFwQT/tiLPrdCQmkqOPzQduxNP0EjATx7TJryM0N9nH54CysN0hHdZ95dbciv91zeSh9QTUA= Received: by 10.67.102.12 with SMTP id e12mr2045990ugm.1181827081160; Thu, 14 Jun 2007 06:18:01 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id i39sm4664146ugd.2007.06.14.06.18.00 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Jun 2007 06:18:00 -0700 (PDT) Message-ID: <46714006.9010107@gmail.com> Date: Thu, 14 Jun 2007 15:17:58 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Marshall Eubanks Subject: Re: [RAM] Ramblings about "locator" References: <4671016C.7090200@gmail.com> <2D7BD830-65B2-44B8-8E70-D6A1955CE540@multicasttech.com> In-Reply-To: <2D7BD830-65B2-44B8-8E70-D6A1955CE540@multicasttech.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 Marshall, ... >> Maybe the essential point is that a locator can at least in >> principle be mapped to topology and an identifier can't. >> > > If in Ethernet what is essentially a random number (the MAC address) > becomes > a locator then maybe the distinction will never be crisp. Well, that horrible thought crossed my mind. I think I disagree with Jarno's comment, because as soon as an Ethernet address gets into a spanning tree it has become a locator (at level 2). Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 09:30: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 1HypPD-00022t-41; Thu, 14 Jun 2007 09:30:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HypPB-00022T-Dl for ram@iab.org; Thu, 14 Jun 2007 09:30:29 -0400 Received: from eastrmmtao103.cox.net ([68.230.240.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HypPA-000557-1A for ram@iab.org; Thu, 14 Jun 2007 09:30:29 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070614133028.PPCC8543.eastrmmtao103.cox.net@eastrmimpo01.cox.net> for ; Thu, 14 Jun 2007 09:30:28 -0400 Received: from [10.30.20.240] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id BRWS1X00Z0pnMhQ0000000; Thu, 14 Jun 2007 09:30:27 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <534C54E7-21C9-4A2F-BC46-585EFCDF5101@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Thu, 14 Jun 2007 09:30:25 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [RAM] Re: Ramblings about "locator" X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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, Brian Carpenter wrote: > I was thinking about why we're having trouble being crisp > about "locator". > > Maybe part of it is that in some contexts, as Noel hinted, > a locator is loaded with topological significance. If the > network topology in a given region is a strict binary > hierarchy, then the locator may be very tightly mapped > to the topology (and is in effect a route). But in other > regions of the network where the topology is an arbitrary > graph, the same locator has no mapping to topology and needs > to be bound to a route by a routing protocol. A locator always has topological significance, IMHO. However, a locator's topological significance is not necessarily bound to a hierarchical bit-pattern (though with IP routing the address does have that sort of binding). > Another thought is that on a classical broadcast Ethernet, > an Ethernet address is a locator, but a rather strange one > in that nobody except the receiver knows where the located > interface is. But the same Ethernet address on a switched > Ethernet or in a spanning tree becomes much more > like a network-level locator; it's mapped to topology by > the switching or bridging mechanism. As someone who builds Ethernet switches these days, my take is that the IEEE MAC address (either 802 or 1394) in an Ethernet frame is an address (i.e. neither identifier, nor locator). A typical Ethernet switch simply has a table inside. One feeds in a destination MAC address and gets back which (bridge/switch) interface(s) to send the frame out. If the target MAC is not in the table, one sends the frame out all interfaces. {The claim that "an IEEE MAC is an Identifier" would be more true if one considered Ethernet-II rather than IEEE 802.3. Ethernet-II said there was one MAC address per node, while 802.3 has one MAC per interface. Both definitions can work fine with off-the-shelf bridging algorithms.} > Maybe the essential point is that a locator can at least in > principle be mapped to topology and an identifier can't. I would phrase it differently. A locator has location semantics, but not identity semantics. An identifier has identity semantics, but not location semantics. An address has both kinds of semantics. So an MAC address in an Ethernet frame is an address. And by the way, I view an EUI-64 (e.g. as used in O'Dell's proposals) to be an Identifier, neither an address nor a locator. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 09: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 1Hypah-0005kw-FN; Thu, 14 Jun 2007 09:42:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hypag-0005kn-61 for ram@iab.org; Thu, 14 Jun 2007 09:42:22 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hypae-0001Sz-V8 for ram@iab.org; Thu, 14 Jun 2007 09:42:22 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0997A87354; Thu, 14 Jun 2007 09:42:12 -0400 (EDT) To: brian.e.carpenter@gmail.com, ram@iab.org Subject: Re: [RAM] Ramblings about "locator" Message-Id: <20070614134212.0997A87354@mercury.lcs.mit.edu> Date: Thu, 14 Jun 2007 09:42:12 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: Brian E Carpenter > I was thinking about why we're having trouble being crisp about > "locator". > Maybe part of it is that in some contexts .. a locator is loaded with > topological significance. > ... > Another thought is that on a classical broadcast Ethernet, an Ethernet > address is a locator .. it's mapped to topology by the switching or > bridging mechanism. > Maybe the essential point is that a locator can at least in principle > be mapped to topology and an identifier can't. Sorry, this is confused. You are confusing two (maybe three) different properties (see my message from yesterday): - What is being named (an interface, etc) - What level the name is at (internetwork, or in the case of the Ethernet address, network) - Location sensitivity (i.e. some information about where the thing is is encoded *directly* into the name) "Locator" means different things to different people (for instance, in GSE it names a subnetwork, not an interface), but AFAIK almost everyone agrees it has the last property. Here's a simple test to see if something has this property: can you look at two *different* names from that namespace, and tell *purely from the names* whether they are in some way 'close' to each other, in locational terms, or not? If not, if you have no idea whether the names are close or far, then the names are *not* locators. Ethernet addresses say *nothing* about *where* an interface is, you can't tell from looking at two what their locational relational status is, so they can't be locators. Also, be careful with the term/concept "mapping". You can (in some designs) map an 'endpoint identifier' a la JNC (which is absolutely not location-sensitive) into some other name, the latter giving you its location. However, that doesn't mean that because the 'endpoint identifier' can "in principle be mapped to topology" that it's a locator. A locator contains, *directly encoded into the name*, information about the location is - and the 'are these two close' test is a simple test for it. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 12:56: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 1Hysc4-0005y3-Of; Thu, 14 Jun 2007 12:56:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hysc3-0005xq-U4 for ram@iab.org; Thu, 14 Jun 2007 12:55:59 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hysc2-0006o3-Jp for ram@iab.org; Thu, 14 Jun 2007 12:55:59 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0F82487363; Thu, 14 Jun 2007 12:55:50 -0400 (EDT) To: ram@iab.org, rja@extremenetworks.com Subject: Re: [RAM] Re: Ramblings about "locator" Message-Id: <20070614165550.0F82487363@mercury.lcs.mit.edu> Date: Thu, 14 Jun 2007 12:55:50 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 > my take is that the IEEE MAC address (either 802 or 1394) in an Ethernet > frame is an address (i.e. neither identifier, nor locator). I was going to assume that what you mean by "identifier" here is 'a name that simply identifies something, without saying anything else about the thing' (which is what I thought you were saying in your previous draft taxomony message). However, that's clearly not the definition you're using, because under that definition, an IEEE MAC address *is* an identifier; it calls out one specific interface, without saying anything else about it (e.g. where it is). (Technically, I know, it's not true that it saying nothing else, because it call tell you who the manufacturer is; yet another semantic axis. But I think we can ignore that axis for the moment.) So I am forced to conclude that you must mean something else by "identifier"; I was thinking that perhaps you implicitly mean that an "identifier" names a transport-level entity - but I don't think you mean that either. This is an example of why I don't like the term "identifier". (To me, all names "identify" *something*; the only question is *what* does it identify, and what are the interesting properties of that name.) And as for using "address" - that term is so hopelessly damaged at this point (except for specific modifier instances like 'IPvN address') that I have no idea what it means (although I like your earlier suggestion that it be defined to be 'a name with the mixed semantics of an ''internetwork locator'' and a ''transport identifier'' ', which is what an 'IPvN address' is) - but if we use that definition, I absolutely cannot see how an IEEE MAC address can be an "address". > {The claim that "an IEEE MAC is an Identifier" would be more true if one > considered Ethernet-II rather than IEEE 802.3. Ethernet-II said there > was one MAC address per node, while 802.3 has one MAC per interface. The issue of whether the namespace allows more than one name to be bound to a single object is yet another independent axis which one can use to describe a namespace. It is not one that I had considered important in deciding whether a particular namespace as a "locator", "identifier", or whatever. Your comment indicates that you do think it is important? >> Maybe the essential point is that a locator can at least in principle >> be mapped to topology and an identifier can't. > A locator has location semantics, but not identity semantics. And what exactly are "identity semantics"? Reading that term de novo, I would assume that it simply means 'a name that identifies an object'; or, from the mathmetical roots, perhaps 'a namespace where names have a one-one correspondence to objects'. > An identifier has identity semantics, but not location semantics. An > address has both kinds of semantics. So an MAC address in an Ethernet > frame is an address. What do you mean by "location semantics"? Do you mean 'a name that includes some information about where the thing is is, encoded *directly* into the name'? I don't think you can, because an Ethernet address doesn't have the property, but by your proposed definition it has "location semantics". Do you "specifies a location"? Also, just because a name identifies a thing which is at a particular location (e.g. an interface), that does not mean that the name has 'location semantics'. To me, there has to be *information* in the name (so that e.g. it can pass the 'are these two close' test). Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 13:25: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 1Hyt4X-0000LN-Cz; Thu, 14 Jun 2007 13:25:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyt4V-0000L4-Vs for ram@iab.org; Thu, 14 Jun 2007 13:25:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyt4U-0004cp-FF for ram@iab.org; Thu, 14 Jun 2007 13:25:23 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2007 13:25:22 -0400 X-IronPort-AV: i="4.16,421,1175486400"; d="scan'208"; a="123636010:sNHT44767114" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5EHPLob022738; Thu, 14 Jun 2007 13:25:21 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5EHOt5p020373; Thu, 14 Jun 2007 17:25:17 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, 14 Jun 2007 13:25:06 -0400 Received: from [192.168.0.5] ([10.82.208.43]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 13:25:06 -0400 In-Reply-To: <534C54E7-21C9-4A2F-BC46-585EFCDF5101@extremenetworks.com> References: <534C54E7-21C9-4A2F-BC46-585EFCDF5101@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: Dino Farinacci Subject: Re: [RAM] Re: Ramblings about "locator" Date: Thu, 14 Jun 2007 10:25:05 -0700 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 14 Jun 2007 17:25:06.0743 (UTC) FILETIME=[F390A470:01C7AEA8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=854; t=1181841922; x=1182705922; c=relaxed/simple; s=rtpdkim1001; 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=20Ramblings=20about=20=22locator=22 |Sender:=20 |To:=20RJ=20Atkinson=20; bh=4gHbjWPmPJsT9eGNlZcAT9+Opy5Fkx23JPKnRdll7Bk=; b=eX3FMSqow63SNTVJqKfQrZPX2u5fym07R6cASrO2YJyf9e4s6gIdZfc6IopslAjH3wRscUPM iT4qDDgGTqiBbq1OM38MY7+/C1rBSnAZy1XDBOnSlA+1h29zAQpITUc6; Authentication-Results: rtp-dkim-1; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > As someone who builds Ethernet switches these days, > my take is that the IEEE MAC address (either 802 or 1394) > in an Ethernet frame is an address (i.e. neither identifier, > nor locator). I disagree. I think it is just as overloaded as an IP address. MAC addresses are used as serial numbers in many products. That is an ID if I ever thought there was one. And a MAC address is certainly used to find (that means "where", and "where" means location) an ethernet attached station in a L2 switched network. And what about how MAC addresses are used in IS-IS and in IPv6 stateless auto-configuration. In these cases, it's purely an ID. And for the old guys, remember OSI and what an L1 area in IS-IS was used for? To route system-ids which were based on MAC addresses. So in this case, the MAC was a locator. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 13:28: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 1Hyt72-0001Y1-65; Thu, 14 Jun 2007 13:28:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyt70-0001Xv-Im for ram@iab.org; Thu, 14 Jun 2007 13:27:58 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyt6z-0005V6-Bc for ram@iab.org; Thu, 14 Jun 2007 13:27:58 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2007 13:27:27 -0400 X-IronPort-AV: i="4.16,421,1175486400"; d="scan'208"; a="123636226:sNHT84012891206" 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 l5EHRPmP009064; Thu, 14 Jun 2007 13:27:25 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5EHR85p021088; Thu, 14 Jun 2007 17:27:25 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 13:26:59 -0400 Received: from [192.168.0.5] ([10.82.208.43]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 13:26:58 -0400 In-Reply-To: <46714006.9010107@gmail.com> References: <4671016C.7090200@gmail.com> <2D7BD830-65B2-44B8-8E70-D6A1955CE540@multicasttech.com> <46714006.9010107@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4FE75876-F899-42F2-9C7E-2676B2E9DEA0@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Ramblings about "locator" Date: Thu, 14 Jun 2007 10:26:58 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 14 Jun 2007 17:26:59.0074 (UTC) FILETIME=[3684FE20:01C7AEA9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=321; t=1181842045; x=1182706045; c=relaxed/simple; s=rtpdkim2001; 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]=20Ramblings=20about=20=22locator=22 |Sender:=20 |To:=20Brian=20E=20Carpenter=20; bh=QlbmQ4fTQr+IFf3LgdZponVSJc1BugiLffWLsbOUtvA=; b=ldD5H6BZtqqaX1DRoUgkQLCcAPqkl7x3TBw3tG2pNLSgFwCm8jEPI7xq+LT7/DirkfsuYOM8 fAemYQYOhFJUeXfvpV5Hvvna+vqA1gVGL+8K5cCyvfvtNa1e/rfjN6f0; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); 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 > Well, that horrible thought crossed my mind. I think I disagree > with Jarno's comment, because as soon as an Ethernet address > gets into a spanning tree it has become a locator (at level 2). Even when it's not in a spanning tree. It is a locator when there are no physical loops as well as in TRILL. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 14:22: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 1HytxJ-0001Cg-69; Thu, 14 Jun 2007 14:22:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HytxH-0001AF-Vh for ram@iab.org; Thu, 14 Jun 2007 14:21:59 -0400 Received: from eastrmmtao104.cox.net ([68.230.240.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HytxG-0002qy-MD for ram@iab.org; Thu, 14 Jun 2007 14:21:59 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070614182158.NAOE8179.eastrmmtao104.cox.net@eastrmimpo01.cox.net>; Thu, 14 Jun 2007 14:21:58 -0400 Received: from [10.30.20.61] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id BWMx1X00j0pnMhQ0000000; Thu, 14 Jun 2007 14:21:58 -0400 In-Reply-To: References: <534C54E7-21C9-4A2F-BC46-585EFCDF5101@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54A6A7F4-4055-48ED-A121-57B6CA0B778F@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Re: Ramblings about "locator" Date: Thu, 14 Jun 2007 14:21:57 -0400 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) 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 14 Jun 2007, at 13:25, Dino Farinacci wrote: > I disagree. I think it is just as overloaded as an IP address. My previous postings have said that things with overloaded semantics (location sometimes, identity other times) are called "addresses". > MAC addresses are used as serial numbers in many products. That is > an ID if I ever thought there was one. And a MAC address is > certainly used to find (that means "where", and "where" means > location) an ethernet attached station in a L2 switched network. Right. Using my terminology proposal, that makes them "addresses" (i.e. objects with mixed semantics, depending on use). > And what about how MAC addresses are used in IS-IS and in IPv6 > stateless auto-configuration. In these cases, it's purely an ID. > > And for the old guys, remember OSI and what an L1 area in IS-IS was > used for? To route system-ids which were based on MAC addresses. So > in this case, the MAC was a locator. So we agree, a MAC is an address -- hence has mixed semantics: sometimes is used for identity and other times used for location. Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 14:35: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 1HyuAC-0000Yh-Rq; Thu, 14 Jun 2007 14:35:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyuAB-0000Yc-L5 for ram@iab.org; Thu, 14 Jun 2007 14:35:19 -0400 Received: from [2001:470:1:1:230:48ff:fe74:fd02] (helo=bender-mail.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyuAA-0005Lj-9o for ram@iab.org; Thu, 14 Jun 2007 14:35:19 -0400 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 828A77DDC for ; Thu, 14 Jun 2007 11:35:14 -0700 (PDT) Received: from JMHLap3.joelhalpern.com (pool-71-240-234-175.fred.east.verizon.net [71.240.234.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 954D57DBE for ; Thu, 14 Jun 2007 11:35:13 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 14 Jun 2007 14:35:08 -0400 To: ram@iab.org From: "Joel M. Halpern" Subject: Re: [RAM] Re: Ramblings about "locator" In-Reply-To: <54A6A7F4-4055-48ED-A121-57B6CA0B778F@extremenetworks.com> References: <534C54E7-21C9-4A2F-BC46-585EFCDF5101@extremenetworks.com> <54A6A7F4-4055-48ED-A121-57B6CA0B778F@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070614183513.954D57DBE@bender.tigertech.net> 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=-2.8 tagged_above=-999.0 required=7.0 tests=ALL_TRUSTED X-Spam-Level: X-Spam-Score: 3.5 (+++) 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 This seems wrong to me. Given any identifier we care to define, someone can later come along and decide to "route" to that over some scope. If that changes the "identifier" into an "address" or a "locator" then the terms do not refer to the name but to the combination on the name and the way it happens to be used, at the moment. That seems wrong. I am driven more and more to a notion along the lines suggested by Mr. Lear, that a locator is a naming string (binary or otherwise) that changes when you change location, and an identifier is a naming string that does not change when one changes location. (Obviously, there are still edge cases.) Or, to paraphrase Noel's description (and to mangle some work from John Day) a locator is where given several such things some notions of distance (closeness, relative topological placement) can be applied to the entities based on those locators. Yours, Joel At 02:21 PM 6/14/2007, RJ Atkinson wrote: >>MAC addresses are used as serial numbers in many products. That is >>an ID if I ever thought there was one. And a MAC address is >>certainly used to find (that means "where", and "where" means >>location) an ethernet attached station in a L2 switched network. > >Right. Using my terminology proposal, that makes them "addresses" >(i.e. objects with mixed semantics, depending on use). _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 14:43: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 1HyuHe-0002UY-A3; Thu, 14 Jun 2007 14:43:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyuHc-0002Rq-SM for ram@iab.org; Thu, 14 Jun 2007 14:43:00 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyuHb-00077j-LF for ram@iab.org; Thu, 14 Jun 2007 14:43:00 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2007 14:26:58 -0400 X-IronPort-AV: i="4.16,421,1175486400"; d="scan'208"; a="123649448:sNHT10238908880" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5EIQvNt015490; Thu, 14 Jun 2007 14:26:57 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5EIQi6H022480; Thu, 14 Jun 2007 18:26:53 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 14:26:47 -0400 Received: from [192.168.0.5] ([10.82.208.43]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 14:26:46 -0400 In-Reply-To: <54A6A7F4-4055-48ED-A121-57B6CA0B778F@extremenetworks.com> References: <534C54E7-21C9-4A2F-BC46-585EFCDF5101@extremenetworks.com> <54A6A7F4-4055-48ED-A121-57B6CA0B778F@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D6902F9-4E69-4100-97AA-E403AE5483DD@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Re: Ramblings about "locator" Date: Thu, 14 Jun 2007 11:26:45 -0700 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 14 Jun 2007 18:26:46.0846 (UTC) FILETIME=[90FF8DE0:01C7AEB1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=320; t=1181845617; x=1182709617; c=relaxed/simple; s=rtpdkim1001; 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=20Ramblings=20about=20=22locator=22 |Sender:=20 |To:=20RJ=20Atkinson=20; bh=H60e0jJ4BkUTuxjuRt4n4HG7V5sUwq6TNa3iCY8ochU=; b=D8zizD7Q0eSB7uUijK8iienf0oWQ9AtelcCiB7zOzNyDttHhLgpfZDpA9uMwnb9gRVcsvF1S /Be0homzG5sYXcTJVEKr2aKtleRiggce21csmWK1stpP/vQ+BUxWXNRq; Authentication-Results: rtp-dkim-1; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); 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 > So we agree, a MAC is an address -- hence has mixed semantics: > sometimes is used for identity and other times used for location. Yes agree what is an address. But to me, especially in this case, an address is both an ID and a Locator. Didn't look close enough to see if you described it that way. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 15:30: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 1Hyv1X-0000Hf-Oi; Thu, 14 Jun 2007 15:30:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyv1W-0000HX-Ek for ram@iab.org; Thu, 14 Jun 2007 15:30:26 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyv1U-0006nG-6S for ram@iab.org; Thu, 14 Jun 2007 15:30:26 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A2F2387361; Thu, 14 Jun 2007 15:30:23 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Re: Ramblings about "locator" Message-Id: <20070614193023.A2F2387361@mercury.lcs.mit.edu> Date: Thu, 14 Jun 2007 15:30:23 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: Dino Farinacci > a MAC address is certainly used to find (that means "where", and > "where" means location) an ethernet attached station in a L2 switched > network. > ... > remember OSI and what an L1 area in IS-IS was used for? To route > system-ids which were based on MAC addresses. So in this case, the MAC > was a locator. I have a hard time figuring out what "locator" means to you all if you think a MAC address is a locator. To me, a name cannot be a locator (or have 'location semantics') unless it has the property that when the thing being named moves to a new location, it needs a new locator (since the locator says 'where' it is). MAC addresses explicitly do not have this property; they *always* stay they same *no matter where* you plug them in and/or move them. Ergo, they are not locators, and have no location semantics. As I said in my previous message: .. just because a name identifies a thing which is at a particular location (e.g. an interface), that does not mean that the name has 'location semantics'. To me, there has to be *information* in the name (so that e.g. it can pass the 'are [the things named by] these two [names] close [to each other]' test). To put it another way, *everything* has a location (or a set of them, e.g. for replicated/distributed objects), and if "locator" simply means 'name of a thing which has a location', that's a non-useful tautology, kind of like saying 'name of a thing which has a name'. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 15:34: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 1Hyv5q-0002Gx-Ui; Thu, 14 Jun 2007 15:34:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyv5q-0002Gr-00 for ram@iab.org; Thu, 14 Jun 2007 15:34:54 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyv5o-0007mq-Pz for ram@iab.org; Thu, 14 Jun 2007 15:34:53 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A2F1E86AE0; Thu, 14 Jun 2007 15:34:52 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Re: Ramblings about "locator" Message-Id: <20070614193452.A2F1E86AE0@mercury.lcs.mit.edu> Date: Thu, 14 Jun 2007 15:34:52 -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: "Joel M. Halpern" > This seems wrong to me. > Given any identifier we care to define, someone can later come along > and decide to "route" to that over some scope. Exactly. > If that changes the "identifier" into an "address" or a "locator" then > the terms do not refer to the name but to the combination on the name > and the way it happens to be used, at the moment. Good point. > a locator is a naming string (binary or otherwise) that changes when > you change location Exactly. > an identifier is a naming string that does not change when one changes > location. This seems like a plausible definition to me. (It leaves out any notion of *what* is being named, but that's OK with me.) All these two terms ("locator" and "identifier") would now signify would be choices along that one 'location' axis which I have previously discussed. > a locator is where given several such things some notions of distance > (closeness, relative topological placement) can be applied to the > entities based on those locators. Exactly. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 16:30: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 1Hyvxn-0004SG-RA; Thu, 14 Jun 2007 16:30:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyvxl-0004Re-OW for ram@iab.org; Thu, 14 Jun 2007 16:30:37 -0400 Received: from eastrmmtao107.cox.net ([68.230.240.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyvxk-0002Gx-FB for ram@iab.org; Thu, 14 Jun 2007 16:30:37 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070614203035.BAPK7972.eastrmmtao107.cox.net@eastrmimpo01.cox.net>; Thu, 14 Jun 2007 16:30:35 -0400 Received: from [10.30.20.61] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id BYWb1X00Q0pnMhQ0000000; Thu, 14 Jun 2007 16:30:35 -0400 In-Reply-To: <20070614193023.A2F2387361@mercury.lcs.mit.edu> References: <20070614193023.A2F2387361@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8A7E8D43-1C74-4466-A6ED-124D47043B05@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Re: Ramblings about "locator" Date: Thu, 14 Jun 2007 16:30:35 -0400 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) 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 14 Jun 2007, at 15:30, Noel Chiappa wrote: > I have a hard time figuring out what "locator" means > to you all if you think a MAC address is a locator. Noel, You were the person who persuaded me, after some resistance on my part, that since the IEEE MAC address is used in a lookup table (either a bridge table or an IPv6 ND table) to forward the frame/packet, therefore the MAC address must have location semantics and so could not be a pure Identifier. Now, you've changed horses and are riding away in the opposite direction. I am pretty confused at this point about what your perspective is. I gather your thinking has evolved since this precise question last came up. Cheers, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 16:33: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 1Hyw0a-0001EU-1N; Thu, 14 Jun 2007 16:33:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyw0Y-0000xd-Mz for ram@iab.org; Thu, 14 Jun 2007 16:33:30 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyw0X-0002vN-Dx for ram@iab.org; Thu, 14 Jun 2007 16:33:30 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5014B212D17; Thu, 14 Jun 2007 23:33:28 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 16A52212D0E; Thu, 14 Jun 2007 23:33:28 +0300 (EEST) Message-ID: <4671A61A.9020000@nomadiclab.com> Date: Thu, 14 Jun 2007 23:33:30 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [RAM] Ramblings about "locator" References: <534C54E7-21C9-4A2F-BC46-585EFCDF5101@extremenetworks.com> <54A6A7F4-4055-48ED-A121-57B6CA0B778F@extremenetworks.com> <20070614183513.954D57DBE@bender.tigertech.net> In-Reply-To: <20070614183513.954D57DBE@bender.tigertech.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: 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 Joel M. Halpern wrote: > [...] and an identifier is a naming string > that does not change when one changes location. Yes. This is actually implied by the Latin word "identificare", which means "to make to resemble" -- e.g., a name with an entity. It implies the stability that we associate with identifiers. A "locator" could possibly be defined as a "description of a location". (I was thinking of defining it as an "identifier for a location", but then found that a locator might actually be relative to the one using it. E.g., a source route consisting of "left's", "right's", and "straight's" could be thought of as a locator, but it would lead to different locations depending on from where it is being followed.) Kind regards, - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 16:47: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 1HywE2-0002Cf-Am; Thu, 14 Jun 2007 16:47:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HywE0-0002Ca-KJ for ram@iab.org; Thu, 14 Jun 2007 16:47:24 -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 1HywDy-0006wU-9q for ram@iab.org; Thu, 14 Jun 2007 16:47:24 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2007 13:47:22 -0700 X-IronPort-AV: i="4.16,422,1175497200"; d="scan'208"; a="494288505:sNHT46196626" 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 l5EKlLVo017471; Thu, 14 Jun 2007 13:47:21 -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 l5EKlDaI020678; Thu, 14 Jun 2007 20:47:13 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, 14 Jun 2007 13:47:13 -0700 Received: from [171.71.55.99] ([171.71.55.99]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 13:47:13 -0700 In-Reply-To: <8A7E8D43-1C74-4466-A6ED-124D47043B05@extremenetworks.com> References: <20070614193023.A2F2387361@mercury.lcs.mit.edu> <8A7E8D43-1C74-4466-A6ED-124D47043B05@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <35B81F87-1B77-47B6-8155-F188AF612AA3@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Re: Ramblings about "locator" Date: Thu, 14 Jun 2007 13:47:11 -0700 To: RJ Atkinson X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 14 Jun 2007 20:47:13.0035 (UTC) FILETIME=[2F65F5B0:01C7AEC5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=815; t=1181854041; x=1182718041; 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]=20Re=3A=20Ramblings=20about=20=22locator=22 |Sender:=20; bh=HSpSEPqv8tCitq8Eyhfbw6kMVzS81Y/rt/jheuj2yvM=; b=ZzzXKOH9mWDntsuz4F+EX/Cwv9pDjVirktchzcjUq6CupYwCZnJvpRFc2LnVUlLC55TVvR7/ mLW/5ASatZCi6lDBR40Rk4/Nr0hek2NPnmj9A2lk0HdoeXoQECXQv5u+jU2bP4xrAqCw99IEIG ecy6wMzX/2hEfSAptccpbMgoY=; 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: 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 Jun 14, 2007, at 1:30 PM, RJ Atkinson wrote: > You were the person who persuaded me, after some > resistance on my part, that since the IEEE MAC address > is used in a lookup table (either a bridge table or an > IPv6 ND table) to forward the frame/packet, therefore > the MAC address must have location semantics and so > could not be a pure Identifier. If we consider forwarding functionality to be the definition of a locator, then we are going to have a very serious issue. Consider other forwarding mechanisms that let you take into account source address, port number, protocol number, DSCP, etc. as part of the forwarding decision. If we follow that logic, the phase of the moon could also be a locator. Is that what we want? I prefer Joel's line of thinking. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 17:17: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 1Hywgz-0006eu-LS; Thu, 14 Jun 2007 17:17:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hywgy-0006ei-Mq for ram@iab.org; Thu, 14 Jun 2007 17:17:20 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hywgx-0007EF-DH for ram@iab.org; Thu, 14 Jun 2007 17:17:20 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9112887361; Thu, 14 Jun 2007 17:17:12 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Re: Ramblings about "locator" Message-Id: <20070614211712.9112887361@mercury.lcs.mit.edu> Date: Thu, 14 Jun 2007 17:17:12 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 > since the IEEE MAC address is used in a lookup table .. to forward the > frame/packet, therefore the MAC address must have location semantics > and so could not be a pure Identifier. Actually, I think I probably said something as follows: If we define 'locator' is a 'internetwork-level location-sensitive name for an interface', then one obvious design option for a 'full' locator, for the typical Ethernet interface, is some sort of hierarchical name for the physical network (i.e. subnet), with the MAC address appended. In other words, an IEEE MAC address is *part* of a locator (if you are defining 'locator' to be 'internetwork-level location-sensitive name for an interface'). Yes, if you plug that interface in somewhere else, the locator changes - but the low-order part (the MAC address) will be the same. Similarly, because to me a 'locator' is the name of an interface, the MAC address (or something that maps to it, as in IPv4) would have to be part of the locator. Does that make sense? > I am pretty confused at this point about what your perspective is. I > gather your thinking has evolved since this precise question last came > up. No, not really. The things I think have changed are that i) I'm more sensitive now to understanding how all these terms (e.g. "locator") all mean different things to different people, and ii) I'm slowly becoming more precise (with all these different axes of name attributes: locationality, level, object, etc) about the taxonomy of names. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 17:40: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 1Hyx2r-00052c-My; Thu, 14 Jun 2007 17:39:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyx2q-00050f-Me for ram@iab.org; Thu, 14 Jun 2007 17:39:56 -0400 Received: from imo-m25.mx.aol.com ([64.12.137.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyx2p-0002XM-Gc for ram@iab.org; Thu, 14 Jun 2007 17:39:56 -0400 Received: from HeinerHummel@aol.com by imo-m25.mx.aol.com (mail_out_v38_r9.2.) id 9.cd1.110e6b3b (42809); Thu, 14 Jun 2007 17:38:04 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Thu, 14 Jun 2007 17:38:04 EDT Subject: Re: [RAM] Re: Ramblings about "locator" To: jnc@mercury.lcs.mit.edu, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5014 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) 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: , Content-Type: multipart/mixed; boundary="===============1015643361==" Errors-To: ram-bounces@iab.org --===============1015643361== Content-Type: multipart/alternative; boundary="-----------------------------1181857084" -------------------------------1181857084 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I looked for the word "ramble" in my English-German dictionary and found: =20 planlos reden =3D talking without any plan =20 All I have learnt from the current discussion is the meaning of this word. =20 Heiner =20 =20 =20 -------------------------------1181857084 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
I looked for the word "ramble" in my English-German dictionar= y=20 and found:
 
planlos reden =3D talking without any plan
 
All I have learnt from the current discussion is the meaning of this=20 word.
 
Heiner
 
 
 -------------------------------1181857084-- --===============1015643361== 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 --===============1015643361==-- From ram-bounces@iab.org Thu Jun 14 23:02: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 1Hz24T-0007wS-Tr; Thu, 14 Jun 2007 23:01:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz24S-0007wN-Kd for ram@iab.org; Thu, 14 Jun 2007 23:01:56 -0400 Received: from ns2.nict.go.jp ([133.243.3.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz24R-0006R2-2r for ram@iab.org; Thu, 14 Jun 2007 23:01:56 -0400 Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns2.nict.go.jp with ESMTP id l5F31n4c026720 for ; Fri, 15 Jun 2007 12:01:49 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id l5F31mRi004276 for ; Fri, 15 Jun 2007 12:01:49 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id l5F31m7N004273 for ; Fri, 15 Jun 2007 12:01:48 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id B27806E27 for ; Fri, 15 Jun 2007 12:01:48 +0900 (JST) Received: from nictkafle (5gou2f-dhcp28.nict.go.jp [133.243.146.188]) by mail2.nict.go.jp (Postfix) with ESMTP id 781D36E00 for ; Fri, 15 Jun 2007 12:01:48 +0900 (JST) From: "Ved Kafle" To: Subject: Re: [RAM] Ramblings about "locator" Date: Fri, 15 Jun 2007 12:03:30 +0900 Message-ID: <000901c7aef9$c3abbb90$bc92f385@nictkafle> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 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 > Marshall, > > ... > >> Maybe the essential point is that a locator can at least in > >> principle be mapped to topology and an identifier can't. > >> > > > > If in Ethernet what is essentially a random number (the MAC > address) > > becomes > > a locator then maybe the distinction will never be crisp. > > Well, that horrible thought crossed my mind. I think I disagree > with Jarno's comment, because as soon as an Ethernet address > gets into a spanning tree it has become a locator (at level 2). So, the distinction between an identifier and a locator is dependent on the avalaibility of routing/switching infrastructure. If networks possess routing/switching insfrastructure based on a identifier namespace, the identifier simultaneously functions as a locator. Ved > > Brian > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 14 23:56: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 1Hz2vV-00039z-Sn; Thu, 14 Jun 2007 23:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz2vU-00039u-N4 for ram@iab.org; Thu, 14 Jun 2007 23:56:44 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz2vR-0001cr-MK for ram@iab.org; Thu, 14 Jun 2007 23:56:44 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id DB4FC59E45; Fri, 15 Jun 2007 13:56:38 +1000 (EST) Message-ID: <46720DED.9090608@firstpr.com.au> Date: Fri, 15 Jun 2007 13:56:29 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1b82b4ba484bbe86cdae6d5f8b2d2ccb Subject: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here are some ideas which as far as I know are novel. I will write them up as an I-D if anyone thinks they might be useful. I may well have made some blunders - please let me know where I am mistaken. The name for this proposal is ViP - Versatile redIrection of Packets. "ViP" is pretty lame, but it worked well for Rock Hudson in 1961 (Lover Come Back To Me, with Doris Day and Tony Randall). - Robin This proposal is intended to be easily incrementally deployable, while I think LISP would be difficult or impossible to incrementally deploy. I am assuming LISP 2 or higher - since 1 or 1.5 has no benefits for the global BGP routing table size, as far as I know. There's no mention of Identifiers or Locators here - just IPv4 addresses. I am thinking in IPv4 terms, but the same scheme may be useful for IPv6. I am borrowing from LISP the concepts of the Ingress Tunnel Router (ITR), the Egress Tunnel Router (ETR), the IP-in-IP tunnelling of packets from ITR to ETR and ETRs being either border routers or internal routers. I assume a centralised database of information which determines how a packet's destination IP address controls the packet being encapsulated to be sent to a specific ETR address. I assume all the ITRs have a full up-to-date copy of this database, via some chained or tree-structured, real-time, "push" update system. The ITR functions in this scheme are performed by "V-routers", meaning "Versatile". In some instances a V-router may also perform something like an ETR function, which I will call a TTR (Translation Tunnel Router) but that is a separate issue. The major differences with respect to LISP are: 1 - LISP-mapped prefixes and individual IP addresses are not within any prefix which is advertised in the BGP system. ViP-mapped prefixes and individual addresses and are always part of a prefix which is advertised in BGP. 2 - With LISP, the ITRs are always located in edge networks. They may be interior routers or the border routers. They accept incoming packets on interfaces which are not connected to eBGP peers. With ViP, the ITR function is performed by a "V-router" which is always a BGP router. The V-router may be a border router - single-homed or multi-homed - or a transit router. If the V-router is a border router, it may accept incoming packets for encapsulation on any of its interfaces: those connecting to eBGP peers and those connecting to internal routers. It makes most sense if the V-router ITR function is implemented as part of the workload of a multihomed border router or a transit router. If this is the case, ViP places all ITRs in the DFZ. However, it would be technically possible to have the ITR function performed by a single-homed border router or by specialised router which has only a single interface which connects to a transit router or to any border router. In principle, the ITR function could be performed by the host which originates the packet, but I intend that the ITR function have a full copy of the global mapping database so this would be extremely costly. 3 - For LISP-mapped addresses to be universally reachable, all edge networks need to implement ITR functions, either at their border router(s) or at one or probably many internal routers. (Alternatively, edge networks would need to change their routing system to forward all packets not covered by a BGP advertised prefix to some external router which would provide the ITR function.) A ViP-mapped address will be universally reachable as long as there is a single reachable V-router which can receive packets from the original sender and send encapsulated packets to the ETR for this address. 4 - Point 3 has a profound effect on how the two proposals may be incrementally deployed. With LISP, there is a serious and perhaps insurmountable barrier to anyone deciding to connect a host to a LISP-mapped address. The first people to do this will find their addresses generally unreachable since virtually no edge networks will have upgraded any of their internal or border routers to perform LISP ITR functions. Why should they? It is a huge investment to enable communications with a handful of rebels who are voluntarily opting out of the BGP system (albeit for the benefit of humanity). I can't imagine how LISP would ever get off the ground, since early adopters would have extremely patchy connectivity. No-one would put a crucial service on a LISP-mapped address. Since all crucial services would be available on ordinary BGP-routed addresses, why should edge networks spend money on a new or upgraded router? ViP requires no changes in the edge network of the sender. It can be implemented with a single ITR on some BGP router somewhere in the world, and a single ETR in the edge network of the destination host. 5 - LISP assumes a single system. I will assume a single ViP system in most of the discussion below, but there could be any number of independent ViP systems in operation, without conflict. Indeed, a ViP system could be a profitable enterprise. 6 - Because LISP needs to be a single system, it needs to be standardised by the IETF and IANA. I think ViP could be implemented without any new IETF standardised protocols or IANA assignments. I am not suggesting this be done - it would be best to create either a single unified ViP system or standards by which multiple ViP systems could all work in the same way. 7 - One of the primary benefit of ViP, together with providing reachability from the outset without requiring sending edge networks to do anything, is that there would be a smaller number of ITRs in the system. These will tend to be bigger than with LISP and will have more intensive work to do. I am thinking of direct RAM-based lookup approaches, involving two or so memory cycles, to speed this operation in hardware. Perhaps one or more models of current high-end router, such as the CRS-1, could perform these functions nicely, with an extensive firmware upgrade. 8 - With ViP, packets to be encapsulated reach the edge of the BGP system or are forwarded within it, either to a single ITR (if the ViP system only has one V-router) or to one of multiple ITR functions in separate V-routers all of which have the same IP address. ViP uses Anycast to provide multiple redundant paths within the BGP system for packets to find their way to an ITR. Anycast is not normally used for TCP communications, but I am hoping it will be appropriate here, since the individual ITRs only encapsulate the packet and tunnel it to the ETR. Assuming the sender Host A (HA) has a BGP-mapped address and the Host B (HB) destination address is ViP-mapped, the packets in the opposite direction use ordinary BGP routers to make their way from HB to HA. If HA also has a ViP-mapped address, the same process occurs in the reverse direction, with the packets leaving HB, and being directed towards the nearest anycast V-router, which performs the ITR function and tunnels the packet to the ETR for HA. If the border routers of both edge networks are V-routers, which perform ITR functions and these same routers are also the ETRs for their hosts, then the paths of the packets will be the same in both directions. 9 - LISP and what I will call "ViP-basic" both have their ETRs in edge networks, or at the border router. These ETRs must have an interface with an IP address which is reachable via the global BGP system. These only handle packets one way - from the sender HA to the LISP/ViP-mapped destination address of HB. Packets in the return direction HA <- HB are sent normally, without relying on tunnelling, if the destination HA's address is not LISP/ViP-mapped. Otherwise, a similar process occurs with the packet being intercepted by an ITR and tunnelled to the ETR which handles HA's address. I will also describe a ViP-mobile system where the tunnel endpoint is an individual host, which establishes the tunnel with either the ITR or a TTR (Translating Tunnel Router) both of which are BGP routers with BGP-routable addresses. The host requires suitable tunnelling software in its operating system or application program, but can be located anywhere on the Internet, including behind NAT. It is conceivable that a fully developed approach to this mobility idea could provide multiple tunnels over different upstream links from the target to one or more TTRs. The tunnel between the TTR and the host would be bi-directional so the mobile host's current ISP doesn't need to know about the mobile host's ViP address, for instance for allowing upstream packets from this address. 10 - With LISP, there are an unknown number of ITRs, since there must be one or more in every edge network if LISP-mapped addresses are to be fully reachable. With a single ViP system, there are a finite and generally smaller number of known ITRs, all part of the BGP network. This makes it practical, or more practical than with LISP, to run a tightly meshed system for distributing updates of the mapping database to each ITR in real-time. If there was a single global ViP system then the ITRs would be operated by multiple ASes. So a considerable amount of coordination would be required. If there were multiple ViP systems, then the ITRs of each system may or may not be run by the one AS. 11 - Since ViP has a smaller number of routers performing the ITR functions, it is more practical to have them contain a complete up-to-date version of the mapping database. This means that there are no delays, as in a LISP variant 2.x or 3.x "pull" model, which needs to request mapping information for packets with destination addresses it does not have mapping information for. LISP variants are listed at: http://www1.ietf.org/mail-archive/web/ram/current/msg01289.html The delay in getting that mapping will usually result in such delays in delivering the packet that the host application or whatever it was which sent it is likely to assume that the packet was dropped. Although ViP could work with a "pull" query and cache system rather than a full database in each ITR, I am proposing every ITR have a database which is up-to-date within a few seconds of any changes being made to the master database in some central, or distributed, control system. There are no-doubt many pitfalls in all this. I am only considering unicast packets, not multicast. Example of ViP-basic -------------------- ASCII Art only works with fixed width fonts: Edge Network A [ITR] HA---(IR)----(BR1NA)------(VR1)-----(TR2)--(TR4) Edge Network B \ \ \ \ \ \ [ETR] (TR1)----(VR2)---(TR3)---(BR1NB)---(IR)---HB \ / \ / (TR5)----(TR6) \ \ Edge Network C \ [ETR] (BR1NC)----HC \ ---HD HA's address is 11.11.11.11, which is part of a prefix which is advertised in BGP and which is not covered by ViP mapping. HB's address is 22.22.0.1, which is part of 22.22.0.0/16, which is also advertised in BGP and which is ViP-mapped. The other hosts' addresses are: HC = 22.22.4.1 HD = 22.22.4.2 There are three border routers and two V-routers. In this initial example of HA sending a packet to HB, the ITR function is performed by VR1. Both VR1 and VR2 also perform normal BGP transit router functions. Edge Network A has no ViP-equipped internal or border routers. Edge Networks B and C have a router which performs ETR functions. In this example, Edge Network B uses an internal router and Edge Network C uses its border router. Edge Networks A and C are singlehomed and B is multihomed. The packet makes its way through Edge Network 1 to BR1NA which recognises it's destination address as being within the BGP advertised prefix 22.22.0.0/16. Both VR1 and VR2 advertise this prefix 22.22.0.0/16. BR1NA forwards the packet to VR1, because this is the closest. If VR1 had become unreachable through that direct link, BR1NA would have forwarded the packet to TR1 instead, which would have forwarded the packet to VR2, which would have performed the same ITR function as I will describe for VR1. VR1 recognises that the destination address of this packet is for a BGP advertised prefix which is covered by ViP mapping. It therefore uses the IP address to look up the IP address of the ETR the packet should be tunnelled to. While it would be possible to ViP-map an entire BGP-advertised prefix to a single ETR, this is not how I intend it operate. To do so would not achieve any reduction in the global BGP routing table. Instead, I intend that ViP-mapping be applied generally to rather large (in terms of number of addresses) prefixes (that is, a short prefix) and that each such prefix should have many fine divisions in terms of which edge networks the ETRs are located in. It is technically possible, although perhaps hard work for the ITR, to have a different ETR for every IP address. In this example, a /16 has 65,536 IP addresses. The mapping is, in part: 22.22.0.0 to 22.22.0.15 ---> Internal router of Edge Network B. 22.22.4.0 to 22.22.4.3 ---> Border router of Edge Network C. In this way, a single BGP prefix could have its packets tunnelled to thousands of edge networks. VR1 IP-in-IP encapsulates the packet and forwards the packet according to the BGP routing system for the address of the IR internal router in Edge Network B. When it arrives there, the Internal Router recognises it as a tunnelled packet, strips off the outer IP header and then processes it as it does any other packet. This causes the packet to be forwarded to HB. In the return direction, it is vital that BR1NB allow packets with the source address of HB into the BGP network. Assuming there is an already existing system of V-routers to perform ITR functions (actually, only one is required) then here is what the administrators of Edge Network B need to do in order to gain ViP-mapped addresses for hosts such as HB. 1 - They need to trust whoever runs the V-routers, which effectively means whoever has been assigned the prefix 22.22.0.0/16 - in this example AS7777. In terms of long-term stability, portability etc. of HB's IP address, everything depends on AS7777 retaining this prefix, and controlling the V-routers so that HB's IP address is correctly handled. AS7777 may charge a fee per IP address or via traffic volume to cover its costs - which are primarily running a bunch of fast, expensive, V-routers at various points in the DFZ, to provide robust coverage for all sources and destinations, without excessively longer routes than would be required if the packets were not being handled with ViP. 2 - They pay a fee, make an arrangement etc. by which they can tell AS7777's system the IP address of the ETR which they want packets tunnelled to, whenever those packets are addressed to HB's new ViP-mapped IP address. In this case, Edge Network B gets 16 IP addresses from AS7777: 22.22.0.0/28. How the ViP-mapping works within a BGP-mapped subnet is a matter for AS7777 to determine. There is not necessarily any reason to stick to binary boundaries. 3 - They set up a router to perform ETR functions. The size and location of this router depends on how much traffic they are expecting on ViP-mapped tunnels. 4 - They configure their routers to handle this 22.22.0.0/28 prefix. They configure HB and any other hosts to have the appropriate addresses. Part of this is ensuring that their border router will allow packets with this source address out to the BGP routing system. HB's ViP-mapped address is reachable by all edge networks, since every edge network will forward the packets to one of the V-routers. Edge Network A is multihomed, and this multihoming applies to the way the packets will reach a nearby V-router in the most efficient fashion. Edge Network B is multihomed, and this applies to how tunnelled packets are delivered to its ETR internal router. Similar principles apply to Edge Network C, except that it is not multihomed. So far, unless I have made a mistake, we have seen how ViP can map a single IP addresses and/or longer prefixes of a single, shorter BGP-advertised prefix to hosts in a very large number of edge networks, each of which needs at least one BGP-advertised prefix in order that its ETR be reachable, and for packets in the reverse direction. Now imagine that HB is owned by company Big Inc. The above example would be the same, except that the actions and responsibilities would be different. 1 - Edge Network B would have already installed an ETR, so its customers could use ViP-mapped addresses. 2 - Big Inc. would have dealt with AS7777 to obtain lasting rights to the prefix 22.22.0.0/28. Edge Network B may have helped them do this. 3 - Big Inc. (perhaps with the help of Edge Network B) registers the address of Edge Network B's ETR with AS7777 as being the ETR for all its 16 IP addresses. Now let's say Big Inc wants to move its HB to another Edge Network E. This involves: 1 - Edge Network E already having an ETR, and configuring it and its network to handle 22.22.0.0/28. 2 - Big Inc. using some kind of real-time, cryptographically secured, update system to change AS7777's system's ViP mapping for 22.22.0.0/28 to the address of the ETR of Edge Network E. Edge Network B doesn't have to do anything. So as long as AS7777 run their V-routers and their database as promised, and as long as Big Inc. can find an ISP which will run an ETR and configure their network accordingly, they can take their AS7777 provided subnet to whichever such ISP they like. Example of ViP-basic on a host-by-host basis -------------------------------------------- It would be possible to implement the ETR function in HB directly. This would enable HB to have its ViP-mapped IP address in any supportive ISP. This doesn't necessarily achieve much, since HB still needs an ordinary BGP-mapped and routed IP address so it can be its own ETR. However, Big Inc does gain completely (at least to ETR supportive ISPs) portable IP addresses, with multihoming (assuming the ISP is multihomed) without burdening the global BGP routing table with another advertised prefix. It can also have a single host, performing its own ETR functions, but operating multiple ViP mapped IP addresses, if that serves any purpose. Traffic Engineering ------------------- In the first example, I think Edge Network B and Big Inc. could work together to fine-tune the ViP-mapping of the one or more IP addresses which are carrying a lot of traffic. Edge Network B may want to balance the load of incoming traffic across its two upstream links. One way of doing this would be to have two ETRs, each with an IP address on a separately advertised BGP prefix. One prefix would be advertised on the link to TR4 and the other on the link to TR3. Then, assuming both ETRs could send packets to HB, it would be possible to control incoming traffic by altering the ViP mapping for HB to one or the other of these ETRs. ViP-Mobile ---------- The purpose of ViP mobile is to enable a single ViP mapped IP address to be reached by virtually any Internet-connected host, including any host which: 1 - Has a direct BGP-routable IP address, or: 2 - Is behind one or more NAT firewalls, but can initiate a tunnel session with one or more TTRs, or: 3 - Is on an IP address which is mapped with ViP-basic. The idea is that the mobile host creates a two-way encrypted tunnel to a TTR, with some mechanisms for: 1 - Choosing a single nearby TTR. 2 - Perhaps maintaining two tunnels with two TTRs, with a fancier ViP mapping system which adapts to tunnel from the ITRs to whichever TTR currently can reach the mobile host. The TTR would function as an ETR for the purposes of packets being sent to the mobile host, but it would send them to the host by a second, encrypted and possibly compressed, VPN tunnel. The TTR would receive packets from the host via the VPN tunnel, and as a first instance, forward them so they were handled by the global BGP routing system. There, they would either be sent directly to their destination. Alternatively, if the destination was a ViP-mapped address, they would be forwarded to the nearest V-router and tunnelled from there. The TTR could also function as a ViP ITR for packets to ViP-mapped addresses. However, being a ViP ITR is an onerous task, even for small packet volumes, unless it uses a pull approach to mapping, which enables it to maintain only a partial version of the mapping database. There is obviously a lot more to think about with mobility. Ordinarily the mobile host can use a tunnel to one active TTR. Ideally this is near the mobile device - which is why a global network of V-routers which can be ITRs and TTRs would be a good thing. The idea is to have very light-weight mobility, with the mobile device automatically finding a nearby TTR, authenticating itself, and being online without any arrangements with whichever ISP it is currently connected to. Placement of V-routers (ITRs) ----------------------------- One way of implementing ViP is to have a single global system, in which case, there could be two models, at least: 1 - No fee associated with the mapping of IP addresses or traffic. In this case, there needs to be some reason why people such as transit providers and ISPs want to run V-routers without being paid for the traffic they must handle. 2 - A single global system with some kind of fee for addresses and/or traffic. This raises questions of charging and billing, and distribution of monies. Although a single ViP system for the whole world is attractive in terms of elegance, if the idea is a good one, there is nothing I know of which would stop any organisation setting up its own ViP network. All it needs is an RIR's agreement to use assigned IP addresses in this way, and then the resources to install and run bunch of V-routers around the world. There could be significant revenue opportunities in privately run ViP systems, as long as there was a well standardised approach to the ETR function, which needs to operate on the border routers or internal routers of many ISPs, before multiple ViP systems would be viable. With many or most ISPs running one or more ETRs for free, as part of their general service to customers, it would be possible for multiple competing ViP systems to work alongside each other, each with one or more largish assignments of BGP-routable address space to split up. If there were four such competing systems, with similar or identical technical principles of operation, there would be opportunities for other companies, such as ISPs, to run a single router which performs the ETR functions for one, two, three or all four of the competing global systems - probably for a fee. An ISP may want to create its own ETR function at its border routers or very close to them, in order to minimise or eliminate outgoing and incoming traffic for ViP-mapped addresses within its own network. For instance, an ISP in Australia might have a ViP-mapped host on its Sydney network, but doesn't want to make all the routers in its other cities aware of that IP address. Hosts in other cities would communicate with the Sydney host via a V-router ITR function, so it would be best if the ISP itself had a V-router in each city, so the packets don't escape to the wider Net en-route to the nearest anycast V-router. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 01:27: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 1Hz4L3-00043v-9f; Fri, 15 Jun 2007 01:27:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4L1-0003xc-9A for ram@iab.org; Fri, 15 Jun 2007 01:27:11 -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 1Hz4L0-00076a-ID for ram@iab.org; Fri, 15 Jun 2007 01:27:11 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2007 22:27:10 -0700 X-IronPort-AV: i="4.16,422,1175497200"; d="scan'208"; a="494406192:sNHT60936668" 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 l5F5RATE017213; Thu, 14 Jun 2007 22:27:10 -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 l5F5Qqtb021613; Fri, 15 Jun 2007 05:27:07 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, 14 Jun 2007 22:27:01 -0700 Received: from [192.168.0.5] ([10.21.93.42]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 22:27:01 -0700 In-Reply-To: <46720DED.9090608@firstpr.com.au> References: <46720DED.9090608@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1FDC4EF3-97D4-4CA7-A7EF-5012D4EA5DB8@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels Date: Thu, 14 Jun 2007 22:27:00 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Jun 2007 05:27:01.0420 (UTC) FILETIME=[CD1FD6C0:01C7AF0D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10035; t=1181885230; x=1182749230; 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]=20ViP=3A=20Anycast=20ITRs=20in=20the=20DFZ=20&= 20mobile=20tunnels |Sender:=20; bh=MWpnK1JIGhJIM4rBSv23en14DbFxk0UNV2VvGeGwJCc=; b=ASrCpM76Y/0nVJpX1HsinnLvo3objpVxSICaN0qqMHP7M6tkXapPSkH6wnjEZHmbjuQiSj5u KwxHWwb2agP0COmTUPaX0u+EbWwia7AoSpzOi87IIN9hkJ4m/wuPJfQ0; 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: d9238570526f12788af3d33c67f37625 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 am borrowing from LISP the concepts of the Ingress Tunnel Router > (ITR), the Egress Tunnel Router (ETR), the IP-in-IP tunnelling of > packets from ITR to ETR and ETRs being either border routers or > internal routers. I assume a centralised database of information > which determines how a packet's destination IP address controls the > packet being encapsulated to be sent to a specific ETR address. I > assume all the ITRs have a full up-to-date copy of this database, > via some chained or tree-structured, real-time, "push" update system. Can you tell me what is different here than LISP plus the use of NERD? > The ITR functions in this scheme are performed by "V-routers", > meaning "Versatile". In some instances a V-router may also perform > something like an ETR function, which I will call a TTR > (Translation Tunnel Router) but that is a separate issue. > > The major differences with respect to LISP are: > > 1 - LISP-mapped prefixes and individual IP addresses are not > within any prefix which is advertised in the BGP system. > > ViP-mapped prefixes and individual addresses and are always > part of a prefix which is advertised in BGP. > > > 2 - With LISP, the ITRs are always located in edge networks. > They may be interior routers or the border routers. They > accept incoming packets on interfaces which are not connected > to eBGP peers. > > With ViP, the ITR function is performed by a "V-router" which > is always a BGP router. The V-router may be a border router > - single-homed or multi-homed - or a transit router. If the > V-router is a border router, it may accept incoming packets > for encapsulation on any of its interfaces: those connecting > to eBGP peers and those connecting to internal routers. > > It makes most sense if the V-router ITR function is implemented > as part of the workload of a multihomed border router or a > transit router. If this is the case, ViP places all ITRs in > the DFZ. > > However, it would be technically possible to have the ITR > function performed by a single-homed border router or by > specialised router which has only a single interface which > connects to a transit router or to any border router. In > principle, the ITR function could be performed by the > host which originates the packet, but I intend that the > ITR function have a full copy of the global mapping database > so this would be extremely costly. Tell me what is different here than a LISP ITR running on a CE router with BGP enabled? > 3 - For LISP-mapped addresses to be universally reachable, all > edge networks need to implement ITR functions, either at > their border router(s) or at one or probably many internal > routers. (Alternatively, edge networks would need to change > their routing system to forward all packets not covered by a > BGP advertised prefix to some external router which would > provide the ITR function.) Robin, this is LISP 1.5, don't you realize that? In LISP 1.5, when EIDs come out of PI space, they cannot be routeable via the BGP Internet, so they use another topology that does carry EIDs. This is exactly what you are describing above. > A ViP-mapped address will be universally reachable as long > as there is a single reachable V-router which can receive > packets from the original sender and send encapsulated packets > to the ETR for this address. When you say LISP-mapped or ViP-mapped, it is not clear to me if you mean "map to" or "map from". Can you please clarify? > 4 - Point 3 has a profound effect on how the two proposals may > be incrementally deployed. With LISP, there is a serious > and perhaps insurmountable barrier to anyone deciding to > connect a host to a LISP-mapped address. The first people > to do this will find their addresses generally unreachable > since virtually no edge networks will have upgraded any > of their internal or border routers to perform LISP ITR > functions. Why should they? It is a huge investment to > enable communications with a handful of rebels who are > voluntarily opting out of the BGP system (albeit for the > benefit of humanity). A LISP site will have to use both PI and PA addresses for some time. However, when it uses PI addresses that *will not* be in the core routing tables, other sites can reach them only if they are LISP enabled. Otherwise, the non-LISP enabled sites will reach the LISP site with PA addresses. So we can still reduce the size of the routing table and arguably more-specific injection from other PA blocks. > I can't imagine how LISP would ever get off the ground, > since early adopters would have extremely patchy > connectivity. No-one would put a crucial service on a > LISP-mapped address. Since all crucial services would > be available on ordinary BGP-routed addresses, why should > edge networks spend money on a new or upgraded router? Because they want better control over their ingress traffic flows. They need the level of indirection to achieve this. > ViP requires no changes in the edge network of the sender. > It can be implemented with a single ITR on some BGP router > somewhere in the world, and a single ETR in the edge > network of the destination host. Can you explain how ViP works with PI addresses? > 6 - Because LISP needs to be a single system, it needs to be LISP needs to be a single system only when the entire network runs on PI addresses. That won't happen for a very long time. > 7 - One of the primary benefit of ViP, together with providing > reachability from the outset without requiring sending > edge networks to do anything, is that there would be a smaller > number of ITRs in the system. These will tend to be bigger > than with LISP and will have more intensive work to do. > > I am thinking of direct RAM-based lookup approaches, involving > two or so memory cycles, to speed this operation in hardware. > Perhaps one or more models of current high-end router, > such as the CRS-1, could perform these functions nicely, > with an extensive firmware upgrade. > > > 8 - With ViP, packets to be encapsulated reach the edge of the > BGP system or are forwarded within it, either to a single > ITR (if the ViP system only has one V-router) or to one > of multiple ITR functions in separate V-routers all of > which have the same IP address. Do you actually think a few ITRs is going to handle the load of the Internet? > > ViP uses Anycast to provide multiple redundant paths > within the BGP system for packets to find their way to > an ITR. Anycast is not normally used for TCP > communications, but I am hoping it will be appropriate > here, since the individual ITRs only encapsulate the > packet and tunnel it to the ETR. I have actually tested LISP using anycast addresses and it has the same property. If ITRs have the following mapping cached: {0.0.0.0/0, 1.1.1.1, 2.2.2.2} where 1.1.1.1 and 2.2.2.2 are anycast addresses, you can have various ITRs use the closest ETRs based on the above locator addresses. In the spec we call these boxes "reencapsulating routers", where the anycast box decapsulates and then does a lookup on the inner DA where it has a different mapping (a list of locators where the site actually is) to reach the site's ETR. > 9 - LISP and what I will call "ViP-basic" both have their ETRs > in edge networks, or at the border router. These ETRs must > have an interface with an IP address which is reachable via the > global BGP system. These only handle packets one way - from > the sender HA to the LISP/ViP-mapped destination address of HB. > Packets in the return direction HA <- HB are sent normally, > without relying on tunnelling, if the destination HA's address > is not LISP/ViP-mapped. Otherwise, a similar process occurs > with the packet being intercepted by an ITR and tunnelled to > the ETR which handles HA's address. This can only work if HA is using a PA address. > Example of ViP-basic > -------------------- > > ASCII Art only works with fixed width fonts: > > > Edge Network A > [ITR] > HA---(IR)----(BR1NA)------(VR1)-----(TR2)--(TR4) Edge Network B > \ \ \ > \ \ \ [ETR] > (TR1)----(VR2)---(TR3)---(BR1NB)---(IR)---HB > \ / > \ / > (TR5)----(TR6) > \ > \ Edge Network C > \ [ETR] > (BR1NC)----HC > \ > ---HD I don't understand the benefit of reducing the number of ITRs but still maintaining an ETR in each site. You still have to manage the ETRs. So the gain is not that great. > HA's address is 11.11.11.11, which is part of a prefix which is > advertised in BGP and which is not covered by ViP mapping. > > HB's address is 22.22.0.1, which is part of 22.22.0.0/16, which is > also advertised in BGP and which is ViP-mapped. The other hosts' > addresses are: > > HC = 22.22.4.1 > HD = 22.22.4.2 If this is the example, why do you need ITRs or ETRs at all? If you have routeable addresses just move the packets as we do today. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 03:06: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 1Hz5su-0001iu-Ur; Fri, 15 Jun 2007 03:06:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5st-0001im-Fn for ram@iab.org; Fri, 15 Jun 2007 03:06:15 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz5ss-0002Wo-Tg for ram@iab.org; Fri, 15 Jun 2007 03:06:15 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id E227F59E4B; Fri, 15 Jun 2007 17:06:11 +1000 (EST) Message-ID: <46723A5A.9000809@firstpr.com.au> Date: Fri, 15 Jun 2007 17:06:02 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels References: <46720DED.9090608@firstpr.com.au> <1FDC4EF3-97D4-4CA7-A7EF-5012D4EA5DB8@cisco.com> In-Reply-To: <1FDC4EF3-97D4-4CA7-A7EF-5012D4EA5DB8@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Hi Dino, You wrote: > Can you tell me what is different here than LISP plus the use of > NERD? http://tools.ietf.org/html/draft-lear-lisp-nerd My understanding of LISP may be faulty, but I thought that the IP addresses which are used as locators do not come from prefixes which are advertised via BGP. Therefore, to my understanding, if a host in an edge network wants to send a packet to such an IP address, the edge network needs a LISP ITR function in one or more routers - either inside the edge network or at the border router. Maybe what I wrote only exposes my misunderstanding of LISP and of other aspects of routing and addressing. If so, hopefully this will have some educational value for others. My mention of anycast is probably wrong. What I want to achieve is multiple routers such as transit or border routers to perform the ITR function, and my plan was that they would all advertise the same prefix: 22.22.0.0/16. I don't know if there is a precedent for this with BGP or whether it is impossible, but anycast is a separate technology which is probably not needed here. >> However, it would be technically possible to have the ITR >> function performed by a single-homed border router or by >> specialised router which has only a single interface which >> connects to a transit router or to any border router. . . . > Tell me what is different here than a LISP ITR running on a CE router > with BGP enabled? There's no technical difference. Its just that, as I understand it, with LISP, the edge network needs to run an ITR if its users are to be able to send packets to LISP-mapped addresses. I am going out and will reply more fully in the next day or so. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 03:11: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 1Hz5yE-0003ly-6y; Fri, 15 Jun 2007 03:11:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5yD-0003ln-Hf for ram@iab.org; Fri, 15 Jun 2007 03:11:45 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz5yC-0003v9-5X for ram@iab.org; Fri, 15 Jun 2007 03:11:45 -0400 Received: by ug-out-1314.google.com with SMTP id m2so867204uge for ; Fri, 15 Jun 2007 00:11:43 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Q5wBxrs/oRW0e3Hp/ZWe3skTKhXQAvvvn0F0irgFeFt8V9Moi+/hLr2dQsjmUmWKtFZCjh4KvrBdrYD/rsQPxogcl40p3kzFKULVlAdC79XF+kP2wWr0+7Y+apK5E7yxq3ceDpMaOKcwikxAMj49IiVdI4BXnlBcrg09pw/i5Tw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=qMnXMSMyGNZx4zKOmsLJN20GwJxaYJCeXQUyBOBuUlyQSCGbKbwLeYiDunqqD0D6xxxX9IJzj/yTlcUqAcVcxtKhAA1goTX2qHJgsQBLSvXmtt6eV91JLlne9FMkkMCk03Pu7Q+SOa7M/jRac0o9Rm1coiNMHNt+VHnBOygePmM= Received: by 10.67.10.18 with SMTP id n18mr2508612ugi.1181891503145; Fri, 15 Jun 2007 00:11:43 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id c1sm1529723ugf.2007.06.15.00.11.42 (version=SSLv3 cipher=RC4-MD5); Fri, 15 Jun 2007 00:11:42 -0700 (PDT) Message-ID: <46723BAD.4060307@gmail.com> Date: Fri, 15 Jun 2007 09:11:41 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Ved Kafle Subject: Re: [RAM] Ramblings about "locator" References: <000901c7aef9$c3abbb90$bc92f385@nictkafle> In-Reply-To: <000901c7aef9$c3abbb90$bc92f385@nictkafle> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 2007-06-15 05:03, Ved Kafle wrote: >> Marshall, >> >> ... >>>> Maybe the essential point is that a locator can at least in >>>> principle be mapped to topology and an identifier can't. >>>> >>> If in Ethernet what is essentially a random number (the MAC >> address) >>> becomes >>> a locator then maybe the distinction will never be crisp. >> Well, that horrible thought crossed my mind. I think I disagree >> with Jarno's comment, because as soon as an Ethernet address >> gets into a spanning tree it has become a locator (at level 2). > > So, the distinction between an identifier and a locator is dependent on > the avalaibility of routing/switching infrastructure. > If networks possess routing/switching insfrastructure based on a > identifier namespace, the identifier simultaneously functions as a > locator. My original RAMble (sorry) ended thus: Maybe the essential point is that a locator can at least in principle be mapped to topology and an identifier can't. I think that's correct and actually consistent with much that's been said. A slightly different way to say it is that a locator is a handle for a route. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 03:13: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 1Hz60C-00040t-6p; Fri, 15 Jun 2007 03:13:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz60B-00040j-TS for ram@iab.org; Fri, 15 Jun 2007 03:13:47 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz609-0004Do-Q6 for ram@iab.org; Fri, 15 Jun 2007 03:13:47 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 15 Jun 2007 00:13:45 -0700 X-IronPort-AV: i="4.16,423,1175497200"; d="scan'208"; a="4958679:sNHT21369120" 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 l5F7Dj3P019039; Fri, 15 Jun 2007 00:13:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5F7DiaI029919; Fri, 15 Jun 2007 07:13:44 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); Fri, 15 Jun 2007 00:13:44 -0700 Received: from [192.168.0.5] ([10.21.86.2]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 00:13:44 -0700 In-Reply-To: <46723A5A.9000809@firstpr.com.au> References: <46720DED.9090608@firstpr.com.au> <1FDC4EF3-97D4-4CA7-A7EF-5012D4EA5DB8@cisco.com> <46723A5A.9000809@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <776CCBA4-FB53-4EC7-9733-C8E1F5CCC67C@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels Date: Fri, 15 Jun 2007 00:13:43 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Jun 2007 07:13:44.0529 (UTC) FILETIME=[B5ACBC10:01C7AF1C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2035; t=1181891625; x=1182755625; 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]=20ViP=3A=20Anycast=20ITRs=20in=20the=20DFZ=20&= 20mobile=20tunnels |Sender:=20; bh=m1vu2xWFJduXI1Y0KG9IOHu+vbuh2bKzzErYLE5Zx6w=; b=MLvsxAFG0ix4fiyU1BAHg/mOSmPStoTuU1prrQSUkwlfT8fQdHxjHwPFaX69kTXhaqks3Mrl kR8wkn3xIfZKDeFTPgIiJbODdTlRn0zNnWoD1SZg0xjQ0UGPYGaUKW/U; 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: 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 > > >> Can you tell me what is different here than LISP plus the use of >> NERD? > > http://tools.ietf.org/html/draft-lear-lisp-nerd I know what NERD is, I want you to tell me what the difference is from what's already published from what you are proposing. > My understanding of LISP may be faulty, but I thought that the IP > addresses which are used as locators do not come from prefixes which > are advertised via BGP. They certainly are, or they aren't very good locators. > Therefore, to my understanding, if a host > in an edge network wants to send a packet to such an IP address, the > edge network needs a LISP ITR function in one or more routers - > either inside the edge network or at the border router. The host sends to an EID, and that requires an ITR to attach locators to the packet. EIDs are not routable in the BGP Internet and Locators are. > My mention of anycast is probably wrong. What I want to achieve is > multiple routers such as transit or border routers to perform the > ITR function, and my plan was that they would all advertise the same > prefix: 22.22.0.0/16. I don't know if there is a precedent for this > with BGP or whether it is impossible, but anycast is a separate > technology which is probably not needed here. I thought you wanted it so you can off-load a single ITR for the entire Internet load. >>> However, it would be technically possible to have the ITR >>> function performed by a single-homed border router or by >>> specialised router which has only a single interface which >>> connects to a transit router or to any border router. > > . . . > >> Tell me what is different here than a LISP ITR running on a CE router >> with BGP enabled? > > There's no technical difference. Its just that, as I understand it, > with LISP, the edge network needs to run an ITR if its users are to > be able to send packets to LISP-mapped addresses. The PE router at an ISP could be an ITR as well. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 03:38: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 1Hz6Nd-0006bp-O0; Fri, 15 Jun 2007 03:38:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6Nb-0006bF-T0 for ram@iab.org; Fri, 15 Jun 2007 03:37:59 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz6Na-0004Aj-K8 for ram@iab.org; Fri, 15 Jun 2007 03:37:59 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DB323212E66; Fri, 15 Jun 2007 10:37:56 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9EAF1212DF2; Fri, 15 Jun 2007 10:37:56 +0300 (EEST) Message-ID: <467241D7.7070800@nomadiclab.com> Date: Fri, 15 Jun 2007 10:37:59 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Robin Whittle Subject: Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels References: <46720DED.9090608@firstpr.com.au> In-Reply-To: <46720DED.9090608@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Robin, is it correct to say that ViP anchors an access (or edge) network's prefix at the V-router somewhere within the DFZ? In this case, I would see a difference between ViP and LISP in terms of responsibilities: - In ViP, it is the responsibility of the destination access network to set up (or subscribe to) the anchor router for its prefix. - LISP relies on a router in (or at the border of) the source access network to perform this functionality. This ViP concept reminds me of Mobile IP (v4 or v6), where a mobile host anchors its home network prefix with a home agent, the location of which is independent of the peer that the mobile host communicates with. Both ViP and Mobile IP use tunneling between the anchor and the destination. In fact, ViP is a proposal for network mobility. It enables an access network to change ISPs (which is nothing else but a topological "movement") without losing reachability via the original prefix. Interesting... - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 03:38: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 1Hz6Nc-0006bO-Fb; Fri, 15 Jun 2007 03:38:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6Na-0006bA-Sg for ram@iab.org; Fri, 15 Jun 2007 03:37:58 -0400 Received: from mu-out-0910.google.com ([209.85.134.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz6NZ-0004Ai-FK for ram@iab.org; Fri, 15 Jun 2007 03:37:58 -0400 Received: by mu-out-0910.google.com with SMTP id g7so870320muf for ; Fri, 15 Jun 2007 00:37:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=jCDd/O8LETu1Zibd0PRS3x9WV7D+Go3QCWWqKRo2SFrom ram-bounces@iab.org Fri Jun 15 03:38: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 1Hz6Nd-0006bp-O0; Fri, 15 Jun 2007 03:38:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6Nb-0006bF-T0 for ram@iab.org; Fri, 15 Jun 2007 03:37:59 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz6Na-0004Aj-K8 for ram@iab.org; Fri, 15 Jun 2007 03:37:59 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DB323212E66; Fri, 15 Jun 2007 10:37:56 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9EAF1212DF2; Fri, 15 Jun 2007 10:37:56 +0300 (EEST) Message-ID: <467241D7.7070800@nomadiclab.com> Date: Fri, 15 Jun 2007 10:37:59 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Robin Whittle Subject: Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels References: <46720DED.9090608@firstpr.com.au> In-Reply-To: <46720DED.9090608@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Robin, is it correct to say that ViP anchors an access (or edge) network's prefix at the V-router somewhere within the DFZ? In this case, I would see a difference between ViP and LISP in terms of responsibilities: - In ViP, it is the responsibility of the destination access network to set up (or subscribe to) the anchor router for its prefix. - LISP relies on a router in (or at the border of) the source access network to perform this functionality. This ViP concept reminds me of Mobile IP (v4 or v6), where a mobile host anchors its home network prefix with a home agent, the location of which is independent of the peer that the mobile host communicates with. Both ViP and Mobile IP use tunneling between the anchor and the destination. In fact, ViP is a proposal for network mobility. It enables an access network to change ISPs (which is nothing else but a topological "movement") without losing reachability via the original prefix. Interesting... - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 03:38: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 1Hz6Nc-0006bO-Fb; Fri, 15 Jun 2007 03:38:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6Na-0006bA-Sg for ram@iab.org; Fri, 15 Jun 2007 03:37:58 -0400 Received: from mu-out-0910.google.com ([209.85.134.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz6NZ-0004Ai-FK for ram@iab.org; Fri, 15 Jun 2007 03:37:58 -0400 Received: by mu-out-0910.google.com with SMTP id g7so870320muf for ; Fri, 15 Jun 2007 00:37:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=jCDd/O8LETu1Zibd0PRS3x9WV7D+Go3QCWWqKRo2SIMCGDkbqUqNy2Hmm6jdROrPd4HgF4IDFjNZAMhR0rpdQe3Jtg7XPVIeVVtjmIOHbVLS8Er9/7orZ1Bhp56eQTi867WKaxO1E04wu+TNeVWm2hz+SK4+rMVUfR3eblslHUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=GhIzp1kECaX9DU1a6HUeq6SjAvfLtfPkSa50qVUwtXtO+No5GOEXhIgTIzD4RZ8mFYKU4BpFTeXepTPq7ka/0e9EHj8p5NMLAk+5YkzgNKHAouTvsQyo3tyB/tdB0XoUHe8aPJDpEEaR8ZKNze0EgVOY2tje/Ew19zwHEwNnQEQ= Received: by 10.82.134.12 with SMTP id h12mr5069949bud.1181893076488; Fri, 15 Jun 2007 00:37:56 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id 2sm2495323nfv.2007.06.15.00.37.52 (version=SSLv3 cipher=RC4-MD5); Fri, 15 Jun 2007 00:37:54 -0700 (PDT) Message-ID: <467241CF.6050408@gmail.com> Date: Fri, 15 Jun 2007 09:37:51 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eliot Lear References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ram@iab.org Subject: [RAM] Re: I-D ACTION:draft-lear-lisp-nerd-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 Hi Eliot, I guess the RAM list is the place for this. I really only have two comments at the moment. > 3.1. NERD Record Format I don't think it's OK only to document the IPv4 format. By the time any of this becomes reality we'll be in real need of IPv6 support. It's much better to design it in now, and include it in the calculations. I think it "only" doubles your EID and RLOC sizes - 64 bits should do fine; even a /64 mask seems unlikely in practice. > 8. Deployment Issues > > While LISP and NERD are intended as experiments at this point, it is > already obvious one must give serious consideration to circular > dependencies with regard to the protocols used and the elements > within them. Indeed one must. I strongly suggest getting rid of your dependency on DNS for NERD bootstrapping and update. I see no way to assert with certainty that http://www.example.com/eiddb/ can be resolved without any indirect dependency on LISP - whereas http://192.0.2.123/eiddb/ or http://[2001:DB8::1234]/eiddb/ could be, by assigning server addresses that are in fact global RLOCs. Also, this way you remove any security issues associated with DNS, and any confusion about IPv4 vs IPv6 connectivity to the servers. Since the NERD sevrvers will be just as crucial to the network as the DNS TLD servers, I don't see a strong argument against managing their IP addresses in much the same way as the TLD servers'. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram IMCGDkbqUqNy2Hmm6jdROrPd4HgF4IDFjNZAMhR0rpdQe3Jtg7XPVIeVVtjmIOHbVLS8Er9/7orZ1Bhp56eQTi867WKaxO1E04wu+TNeVWm2hz+SK4+rMVUfR3eblslHUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=GhIzp1kECaX9DU1a6HUeq6SjAvfLtfPkSa50qVUwtXtO+No5GOEXhIgTIzD4RZ8mFYKU4BpFTeXepTPq7ka/0e9EHj8p5NMLAk+5YkzgNKHAouTvsQyo3tyB/tdB0XoUHe8aPJDpEEaR8ZKNze0EgVOY2tje/Ew19zwHEwNnQEQ= Received: by 10.82.134.12 with SMTP id h12mr5069949bud.1181893076488; Fri, 15 Jun 2007 00:37:56 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id 2sm2495323nfv.2007.06.15.00.37.52 (version=SSLv3 cipher=RC4-MD5); Fri, 15 Jun 2007 00:37:54 -0700 (PDT) Message-ID: <467241CF.6050408@gmail.com> Date: Fri, 15 Jun 2007 09:37:51 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eliot Lear References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ram@iab.org Subject: [RAM] Re: I-D ACTION:draft-lear-lisp-nerd-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 Hi Eliot, I guess the RAM list is the place for this. I really only have two comments at the moment. > 3.1. NERD Record Format I don't think it's OK only to document the IPv4 format. By the time any of this becomes reality we'll be in real need of IPv6 support. It's much better to design it in now, and include it in the calculations. I think it "only" doubles your EID and RLOC sizes - 64 bits should do fine; even a /64 mask seems unlikely in practice. > 8. Deployment Issues > > While LISP and NERD are intended as experiments at this point, it is > already obvious one must give serious consideration to circular > dependencies with regard to the protocols used and the elements > within them. Indeed one must. I strongly suggest getting rid of your dependency on DNS for NERD bootstrapping and update. I see no way to assert with certainty that http://www.example.com/eiddb/ can be resolved without any indirect dependency on LISP - whereas http://192.0.2.123/eiddb/ or http://[2001:DB8::1234]/eiddb/ could be, by assigning server addresses that are in fact global RLOCs. Also, this way you remove any security issues associated with DNS, and any confusion about IPv4 vs IPv6 connectivity to the servers. Since the NERD sevrvers will be just as crucial to the network as the DNS TLD servers, I don't see a strong argument against managing their IP addresses in much the same way as the TLD servers'. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 03:48: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 1Hz6XQ-0007uB-0c; Fri, 15 Jun 2007 03:48:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6XO-0007u3-Ia for ram@iab.org; Fri, 15 Jun 2007 03:48:06 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz6XM-0007bK-Ks for ram@iab.org; Fri, 15 Jun 2007 03:48:06 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id A028459E4A; Fri, 15 Jun 2007 17:48:02 +1000 (EST) Message-ID: <46724429.1040909@firstpr.com.au> Date: Fri, 15 Jun 2007 17:47:53 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels References: <46720DED.9090608@firstpr.com.au> <1FDC4EF3-97D4-4CA7-A7EF-5012D4EA5DB8@cisco.com> <46723A5A.9000809@firstpr.com.au> <776CCBA4-FB53-4EC7-9733-C8E1F5CCC67C@cisco.com> In-Reply-To: <776CCBA4-FB53-4EC7-9733-C8E1F5CCC67C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Hi Dino, The NERD url was to save other people looking it up. I apologise for writing: >> My understanding of LISP may be faulty, but I thought that the IP >> addresses which are used as locators do not come from prefixes which >> are advertised via BGP. I meant "addresses which are used as identifiers". >> Therefore, to my understanding, if a host >> in an edge network wants to send a packet to such an IP address, the >> edge network needs a LISP ITR function in one or more routers - >> either inside the edge network or at the border router. > > The host sends to an EID, and that requires an ITR to attach locators to > the packet. EIDs are not routable in the BGP Internet and Locators are. With my proposal, the IP address the sending host uses as an EID is part of a prefix which is routable via BGP on the Net. The idea is that it gets forwarded to an ITR, one of potentially many, which may be at the border of the sending host's edge network but may also be somewhere in the "core" of the Net - meaning not at the border of an edge network: a transit router or perhaps some separate specialised ITR connected to transit and edge routers, but not part of any edge network. If the ITR treated the entire advertised prefix the same, such as tunnelling all packets addressed to the BGP-advertised prefix to a single ETR, there would be little or no benefit. The idea is that it can split up that prefix's address range arbitrarily, potentially down to individual IP addresses, and tunnel each one to a different, independently controlled, ETR. I understand that LISP can do the same. >> My mention of anycast is probably wrong. What I want to achieve is >> multiple routers such as transit or border routers to perform the >> ITR function, and my plan was that they would all advertise the same >> prefix: 22.22.0.0/16. I don't know if there is a precedent for this >> with BGP or whether it is impossible, but anycast is a separate >> technology which is probably not needed here. > > I thought you wanted it so you can off-load a single ITR for the entire > Internet load. No - lots of ITRs, but with ViP there doesn't need to be an ITR in an edge network for hosts in those networks to be able to send packets to an IP address for which ViP mapping exists. Without LISP- or ViP-mapping, all the packets which match a BGP advertised prefix get forwarded to the one border router. With a LISP- or ViP-mapped address, the ITR can tunnel the packets to any ETR which is ready to accept them, with a different ETR per "EID" IP address, if necessary. >>>> However, it would be technically possible to have the ITR >>>> function performed by a single-homed border router or by >>>> specialised router which has only a single interface which >>>> connects to a transit router or to any border router. >> >> . . . >> >>> Tell me what is different here than a LISP ITR running on a CE router >>> with BGP enabled? >> >> There's no technical difference. Its just that, as I understand it, >> with LISP, the edge network needs to run an ITR if its users are to >> be able to send packets to LISP-mapped addresses. > > The PE router at an ISP could be an ITR as well. Yes, for both LISP and ViP. (If anyone can think of a better name . . . .) Christian, I think you understand what I am trying to say. It is not very complex and I don't expect it is very novel. But since I couldn't think of anything which does exactly this, I wrote it up. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 03:55: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 1Hz6eC-00021s-Oe; Fri, 15 Jun 2007 03:55:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6eB-00021k-9b for ram@iab.org; Fri, 15 Jun 2007 03:55:07 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz6e8-0000jj-Vr for ram@iab.org; Fri, 15 Jun 2007 03:55:07 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 15 Jun 2007 00:54:58 -0700 X-IronPort-AV: i="4.16,423,1175497200"; d="scan'208"; a="162723429:sNHT41028975" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5F7swpt004416; Fri, 15 Jun 2007 00:54:58 -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 l5F7sv20009499; Fri, 15 Jun 2007 07:54:57 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); Fri, 15 Jun 2007 00:54:57 -0700 Received: from [192.168.0.5] ([10.21.86.2]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 00:54:57 -0700 In-Reply-To: <46724429.1040909@firstpr.com.au> References: <46720DED.9090608@firstpr.com.au> <1FDC4EF3-97D4-4CA7-A7EF-5012D4EA5DB8@cisco.com> <46723A5A.9000809@firstpr.com.au> <776CCBA4-FB53-4EC7-9733-C8E1F5CCC67C@cisco.com> <46724429.1040909@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D449908-6773-4AFB-A2E7-C3C669229F53@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels Date: Fri, 15 Jun 2007 00:54:56 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Jun 2007 07:54:57.0133 (UTC) FILETIME=[777629D0:01C7AF22] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=451; t=1181894098; x=1182758098; 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]=20ViP=3A=20Anycast=20ITRs=20in=20the=20DFZ=20&= 20mobile=20tunnels |Sender:=20; bh=X7ZEkPPpz6BnnSaCNCrlToL/iuGBG3Z9gGiQtgTqV/k=; b=o8mTfivole2rl2QToowZTKPA/quMB5Avv0qs+5ODlSExVECb4D0zS+eh0AOEjBLSuaozKgVL L3YZyfh0z3QcT+RITtSGBebPzi3t2w7GfncIg2ALn49lN09JAka+y4HA/8uTvUcDETjID3SmzD w6xR773lENlukjotFW+zyjEsA=; 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: 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 > Christian, I think you understand what I am trying to say. It is > not very complex and I don't expect it is very novel. But since I > couldn't think of anything which does exactly this, I wrote it up. But you require your address to be routeable all the time. If a site requests Provider Independent (PI) addresses, your proposal requires them to be routed in the core. That will not reduce the size of the routing tables. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 04:03: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 1Hz6lj-0008Ju-7h; Fri, 15 Jun 2007 04:02:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6lg-0008Jm-7h for ram@iab.org; Fri, 15 Jun 2007 04:02:52 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz6le-0003K8-U9 for ram@iab.org; Fri, 15 Jun 2007 04:02:52 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2007 10:02:50 +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 l5F82ocY030543; Fri, 15 Jun 2007 10:02:50 +0200 Received: from elear-mac.local (ams3-vpn-dhcp4516.cisco.com [10.61.81.163]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5F82nDR028496; Fri, 15 Jun 2007 08:02:49 GMT Message-ID: <467247A8.1060707@cisco.com> Date: Fri, 15 Jun 2007 09:02:48 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Brian E Carpenter References: <467241CF.6050408@gmail.com> In-Reply-To: <467241CF.6050408@gmail.com> 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=1505; t=1181894570; x=1182758570; 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=20I-D=20ACTION=3Adraft-lear-lisp-nerd-01.txt |Sender:=20; bh=Sz7UDLK8GMczxIIL2zCwnVp0AbQU0VeLxeH/hNJSW5c=; b=CnGmsGc953OYuKXDELX+HJmLiyk4bWbSjAuhEGXVVzxIikUBHQO3qa//3ME+iF477JFWnqnb 0TQA8hM2213LrF6LY0O7CuX+So89b5n6Tz4P0QRpgXyLTyXEoQMRWTFT; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ram@iab.org Subject: [RAM] Re: I-D ACTION:draft-lear-lisp-nerd-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 Brian E Carpenter wrote: > Hi Eliot, > > I guess the RAM list is the place for this. I really only > have two comments at the moment. > > > 3.1. NERD Record Format > > I don't think it's OK only to document the IPv4 format. > By the time any of this becomes reality we'll be in real need of > IPv6 support. It's much better to design it in now, and include > it in the calculations. Hmm... You'll note the AFI in the record format. The analysis is IPv4, and it is worth mentioning how IPv6 would impact it. Your analysis below seems accurate. > > I think it "only" doubles your EID and RLOC sizes - 64 bits should > do fine; even a /64 mask seems unlikely in practice. > > > 8. Deployment Issues > > > > While LISP and NERD are intended as experiments at this point, it is > > already obvious one must give serious consideration to circular > > dependencies with regard to the protocols used and the elements > > within them. > > Indeed one must. I strongly suggest getting rid of your dependency > on DNS for NERD bootstrapping and update. I see no way to assert > with certainty that http://www.example.com/eiddb/ can be resolved without > any indirect dependency on LISP I would argue that name servers and NERD web servers involved should have globally routed addresses. This resolves the interdependencies. I see no reason, by the way, why everyone must use LISP ETRs and PI space. If you are single homed, what's the benefit? Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 04:23: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 1Hz75W-0003Jl-7i; Fri, 15 Jun 2007 04:23:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz75V-0003Jf-9e for ram@iab.org; Fri, 15 Jun 2007 04:23:21 -0400 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz75U-0000al-L9 for ram@iab.org; Fri, 15 Jun 2007 04:23:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 4E707B5B48; Fri, 15 Jun 2007 10:23:19 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07727-01-15; Fri, 15 Jun 2007 10:23:19 +0200 (CEST) Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:7:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id 02392B5B43; Fri, 15 Jun 2007 10:23:19 +0200 (CEST) Message-ID: <46724C76.80707@uninett.no> Date: Fri, 15 Jun 2007 10:23:18 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.0 (X11/20070529) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [RAM] Ramblings about "locator" References: <000901c7aef9$c3abbb90$bc92f385@nictkafle> <46723BAD.4060307@gmail.com> In-Reply-To: <46723BAD.4060307@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -2.8 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ram@iab.org, Ved Kafle X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Brian E Carpenter wrote: > On 2007-06-15 05:03, Ved Kafle wrote: >>> Marshall, >>> >>> ... >>>>> Maybe the essential point is that a locator can at least in >>>>> principle be mapped to topology and an identifier can't. >>>>> >>>> If in Ethernet what is essentially a random number (the MAC >>> address) >>>> becomes >>>> a locator then maybe the distinction will never be crisp. >>> Well, that horrible thought crossed my mind. I think I disagree >>> with Jarno's comment, because as soon as an Ethernet address >>> gets into a spanning tree it has become a locator (at level 2). >> >> So, the distinction between an identifier and a locator is dependent on >> the avalaibility of routing/switching infrastructure. If networks >> possess routing/switching insfrastructure based on a >> identifier namespace, the identifier simultaneously functions as a >> locator. Yes, I would say that it functions as a locator, but I'm not sure I would say that it is a locator. Does the fact that you know where all the identifiers are located make them locators? > My original RAMble (sorry) ended thus: > > Maybe the essential point is that a locator can at least in > principle be mapped to topology and an identifier can't. So I'm not sure exactly what "mapped to topology" should mean, but I think I do. I would not say that MAC addresses can be mapped, their values are not tied to the topology in any way. Stig > I think that's correct and actually consistent with much that's been > said. A slightly different way to say it is that a locator is a > handle for a route. > > 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 Fri Jun 15 04:32: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 1Hz7E5-0000mX-RX; Fri, 15 Jun 2007 04:32:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz7E5-0000mS-DN for ram@iab.org; Fri, 15 Jun 2007 04:32:13 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz7E4-0002jc-0l for ram@iab.org; Fri, 15 Jun 2007 04:32:13 -0400 Received: by ug-out-1314.google.com with SMTP id m2so877919uge for ; Fri, 15 Jun 2007 01:32:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=I0HrrDF01cPfIzF5M5OD5FiSnQPez3qtlJ4U+uXXjKgRq25g1ES7BCwugbWN7J07N1f4aF/8LscgWaHtQNpr4fr1qomxSFCtrLiBz4qagHB5lslS5OrSZm3GXeNHTBh3Zf/nlui6KKWenclWjM8xS7vNX4Rjo8xMz3qlc3T2LxI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=eaXaCAF42mfGIh4GANIwDa2fTxiwTvqF5B/v+xRW3gPnmo72QOU+q86WlkThOlwRh4kJcHHd3hQvi59ckaLo97AnxvyOFWicNwrWi6NAEENh4Mp/RCHcnPIrlqxSbodHk2OWSb22NRjwFZ33IZRIi+Ri43wBNJwq9b9q9aptALw= Received: by 10.82.178.11 with SMTP id a11mr5139164buf.1181896331051; Fri, 15 Jun 2007 01:32:11 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id h6sm2919053nfh.2007.06.15.01.32.10 (version=SSLv3 cipher=RC4-MD5); Fri, 15 Jun 2007 01:32:10 -0700 (PDT) Message-ID: <46724E89.3010101@gmail.com> Date: Fri, 15 Jun 2007 10:32:09 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eliot Lear References: <467241CF.6050408@gmail.com> <467247A8.1060707@cisco.com> In-Reply-To: <467247A8.1060707@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ram@iab.org Subject: [RAM] Re: I-D ACTION:draft-lear-lisp-nerd-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 2007-06-15 10:02, Eliot Lear wrote: > Brian E Carpenter wrote: >> Hi Eliot, >> >> I guess the RAM list is the place for this. I really only >> have two comments at the moment. >> >> > 3.1. NERD Record Format >> >> I don't think it's OK only to document the IPv4 format. >> By the time any of this becomes reality we'll be in real need of >> IPv6 support. It's much better to design it in now, and include >> it in the calculations. > > Hmm... You'll note the AFI in the record format. The analysis is IPv4, > and it is worth mentioning how IPv6 would impact it. Your analysis > below seems accurate. > >> >> I think it "only" doubles your EID and RLOC sizes - 64 bits should >> do fine; even a /64 mask seems unlikely in practice. >> >> > 8. Deployment Issues >> > >> > While LISP and NERD are intended as experiments at this point, it is >> > already obvious one must give serious consideration to circular >> > dependencies with regard to the protocols used and the elements >> > within them. >> >> Indeed one must. I strongly suggest getting rid of your dependency >> on DNS for NERD bootstrapping and update. I see no way to assert >> with certainty that http://www.example.com/eiddb/ can be resolved without >> any indirect dependency on LISP > > I would argue that name servers and NERD web servers involved should > have globally routed addresses. This resolves the interdependencies. I > see no reason, by the way, why everyone must use LISP ETRs and PI > space. If you are single homed, what's the benefit? But how do you know that *all* the routes involved in DNS transactions, including caching, and zone transfers, are working when the NERD has not been fully updated? I don't see how you can prove that there is no circularity. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 06:08: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 1Hz8ij-0003P3-Co; Fri, 15 Jun 2007 06:07:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz8ig-0003Op-ME for ram@iab.org; Fri, 15 Jun 2007 06:07:54 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz8if-0001sz-D0 for ram@iab.org; Fri, 15 Jun 2007 06:07:54 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2007 12:07:53 +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 l5FA7qq3030308; Fri, 15 Jun 2007 12:07:52 +0200 Received: from elear-mac.local (ams3-vpn-dhcp4110.cisco.com [10.61.80.13]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5FA7pDR009878; Fri, 15 Jun 2007 10:07:52 GMT Message-ID: <467264F7.2020403@cisco.com> Date: Fri, 15 Jun 2007 11:07:51 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Brian E Carpenter References: <467241CF.6050408@gmail.com> <467247A8.1060707@cisco.com> <46724E89.3010101@gmail.com> In-Reply-To: <46724E89.3010101@gmail.com> 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=1279; t=1181902072; x=1182766072; 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=20I-D=20ACTION=3Adraft-lear-lisp-nerd-01.txt |Sender:=20; bh=XCWuYr/qrZcTQo2uHloRcYjUPvx9puE4mU39UI2hqLA=; b=ZVGbAygYKSg7V6b1lTzBpQB2DJZpmFKj4I1KgZteREJx8hFtIqH1UoLxJBR0yr1za/kVrwdk ZTn1kj406XvuJbnaSarRopggxMQrqFvMep32MLJlBw8frB/oKL8UiJv3; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ram@iab.org Subject: [RAM] Re: I-D ACTION:draft-lear-lisp-nerd-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 Brian E Carpenter wrote: > But how do you know that *all* the routes involved in DNS transactions, > including caching, and zone transfers, are working when the NERD has not > been fully updated? I don't see how you can prove that there is no > circularity. There is direct feedback if you get this wrong, and there is a known solution to getting it right. Anytime you use LISP you will need to worry about circular dependencies, because in a sense we are simply recursing the routing. That doesn't mean that the problem is insurmountable, but rather that one needs to apply some caution. There is also a way for mission critical devices for LISP are going to create such a circular dependency: grab a copy of the NERD and see if your own address is listed. Does this make the Internet more fragile? I would argue only VERY marginally, and that the problem is bilateral in nature, meaning that one of the two communicating parties can step in to fix it. Another approach to all of this would be to simply multicast the database as we do with OSPF today. I see nothing wrong with such an approach in principle, but I have not considered the details. That's more code to write, and it does not seem necessary as a starting point. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 07:02: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 1Hz9Zn-0000WF-HY; Fri, 15 Jun 2007 07:02:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz9Zm-0000U1-9J for ram@iab.org; Fri, 15 Jun 2007 07:02:46 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz9Zk-0007kU-Tx for ram@iab.org; Fri, 15 Jun 2007 07:02:46 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 559361C00E9 for ; Fri, 15 Jun 2007 13:02:44 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 511A31C00E0 for ; Fri, 15 Jun 2007 13:02:44 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 4DC0758EBE6 for ; Fri, 15 Jun 2007 13:02:44 +0200 (CEST) Date: Fri, 15 Jun 2007 13:02:44 +0200 From: Stephane Bortzmeyer To: ram@iab.org Message-ID: <20070615110244.GB26850@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [RAM] Re: I-D ACTION:draft-lear-lisp-nerd-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, Jun 13, 2007 at 06:50:02PM -0400, Internet-Drafts@ietf.org wrote a message of 97 lines which said: > Title : NERD: A Not-so-novel EID to RLOC Database > Author(s) : E. Lear > First, the obvious concern is that XML is not known for efficiency > of data transport. This argument no longer holds if you use compression. The figures you mention for compression are for the efficient binary format but, with XML, you have have higher ratios and may be bring XML database size down to the size of the binary one. Also, there is no discussion of JSON? (RFC 4627) > The other concern about XML is that version 1.0 of the specification > is silent on the order of sibling elements. This is not true. The specification uses the word "sequence" which is very clear in mathematics and computer science. It implies order. Also, in the context of security and cryptographic signature that you mention, the specifications of XML Signature (http://www.w3.org/TR/xmldsig-core/) and Canonical XML (http://www.w3.org/TR/xml-c14n) contain everything you need to be sure that the issue will not be a problem. > [13] Huitema, C., "An Experiment in DNS Based IP Routing", RFC 1383, > December 1992. > Several recent studies have outlined the risk of "routing explosion" > in the current Internet: there are already more than 5000 networks > announced in the NSFNET routing tables, Indeed, the sky is falling :-) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 08:50: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 1HzBFp-0002qR-Dj; Fri, 15 Jun 2007 08:50:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBFn-0002kD-GD for ram@iab.org; Fri, 15 Jun 2007 08:50:15 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzBFm-0001AO-8y for ram@iab.org; Fri, 15 Jun 2007 08:50:15 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D2E5C86AF7; Fri, 15 Jun 2007 08:50:13 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Ramblings about "locator" Message-Id: <20070615125013.D2E5C86AF7@mercury.lcs.mit.edu> Date: Fri, 15 Jun 2007 08:50:13 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: Brian E Carpenter > My original RAMble (sorry) ended thus: > Maybe the essential point is that a locator can at least in > principle be mapped to topology and an identifier can't. My human-name can be mapped to a telephone number. My human-name is not, however, a telephone number. An "identifier" can certainly be mapped to a network location with the aid of the appropriate database, just as a DNS name can be mapped to a network location. Maybe you're using the wrong word, and instead of "mapped" you really meant something like 'directly related', or something like that, but the problem is that that's a somewhat nebulous turn of phrase. Which is why I previously suggested that nice gold-standard, easily-comprehendable tests for 'does this name have location information embedded in it' are: - Do you have to get a new one when you move to a new location? - Given two location-based names, can you tell, by comparing *just the names*, whether they are 'close' to each other? Maybe someone else can come up with a snappy word/phrase which clearly, cleanly and concisely embodies that very close relationship... > A slightly different way to say it is that a locator is a handle for > a route. No. My street address is not a handle (in any simple sense) for directions to my house. Yes, with a lot of data (connectivity information), and a certain amount of computing, it can be turned into directions, but the relationship is not a simple one. This was all quite clear a long time ago; see IEN-19, John Shoch, "Inter-Network Naming, Addressing, and Routing", January 1978, now finally available at: ftp://ftp.isi.edu/in-notes/ien/ien19.txt Everyone here should be familiar with what it has to say. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 09:23: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 1HzBm8-0003AV-NG; Fri, 15 Jun 2007 09:23:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBm8-0003AI-0M for ram@iab.org; Fri, 15 Jun 2007 09:23:40 -0400 Received: from web58701.mail.re1.yahoo.com ([66.196.100.123]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HzBm7-0002Dr-7O for ram@iab.org; Fri, 15 Jun 2007 09:23:39 -0400 Received: (qmail 74609 invoked by uid 60001); 15 Jun 2007 13:23:38 -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=h4c7gI/Wxu8rZqP0CxF3ePUTUmrLCtnnoNgeDEwwHpdEzyWq99h17Qpt5eukd0kLYuoIA7CixSYvlMKHkmbT0j+UTOHrJnhX3CxmZr8wFL0w3FQovP6rkTUDFSUn3eIws+yaHA1PGujzeHK+Oxlzc/05i5M1ujlgtzuWKvYF70I=; X-YMail-OSG: MSGgXzgVM1kE67_.dA16uyt2Wlbs2Jdpqlgkom08D5PsZleEfQN.sazAGTL5myqDdw-- Received: from [24.114.255.3] by web58701.mail.re1.yahoo.com via HTTP; Fri, 15 Jun 2007 06:23:38 PDT Date: Fri, 15 Jun 2007 06:23:38 -0700 (PDT) From: Peter Sherbin Subject: Re: [RAM] Re: Ramblings about "locator" To: Tony Li , RJ Atkinson In-Reply-To: <35B81F87-1B77-47B6-8155-F188AF612AA3@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <935775.74605.qm@web58701.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 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 > If we consider forwarding functionality to be the definition of a > locator, then we are going to have a very serious issue. The above should not be a constrain or concern because in the new architecture under discussion all current principles may not need to apply. E.g. current address vs. future id / loc split. Thanks, Peter --- Tony Li wrote: > > On Jun 14, 2007, at 1:30 PM, RJ Atkinson wrote: > > > You were the person who persuaded me, after some > > resistance on my part, that since the IEEE MAC address > > is used in a lookup table (either a bridge table or an > > IPv6 ND table) to forward the frame/packet, therefore > > the MAC address must have location semantics and so > > could not be a pure Identifier. > > > If we consider forwarding functionality to be the definition of a > locator, then we are going to have a very serious issue. Consider > other forwarding mechanisms that let you take into account source > address, port number, protocol number, DSCP, etc. as part of the > forwarding decision. If we follow that logic, the phase of the moon > could also be a locator. Is that what we want? > > I prefer Joel's line of thinking. > > Tony > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 09:48: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 1HzCAA-00059i-CT; Fri, 15 Jun 2007 09:48:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCA8-00059M-GR for ram@iab.org; Fri, 15 Jun 2007 09:48:28 -0400 Received: from eastrmmtao103.cox.net ([68.230.240.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzCA7-0008K7-6H for ram@iab.org; Fri, 15 Jun 2007 09:48:28 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070615134826.BKAY8543.eastrmmtao103.cox.net@eastrmimpo01.cox.net> for ; Fri, 15 Jun 2007 09:48:26 -0400 Received: from [10.30.20.61] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id BpoS1X0080pnMhQ0000000; Fri, 15 Jun 2007 09:48:26 -0400 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: RJ Atkinson Date: Fri, 15 Jun 2007 09:48:25 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.6 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [RAM] (no subject) X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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, Ved Kafle wrote: > So, the distinction between an identifier and a locator is > dependent on > the avalaibility of routing/switching infrastructure. > If networks possess routing/switching insfrastructure based on a > identifier namespace, the identifier simultaneously functions as a > locator. No. An identifier cannot ever be a locator -- and the inverse is also true. If one has an object that functions both for identity and location, that object is an "address", and is NOT an "identifier" or a "locator". Cheers, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 09:53: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 1HzCER-0006Qq-J5; Fri, 15 Jun 2007 09:52:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCEQ-0006QN-El for ram@iab.org; Fri, 15 Jun 2007 09:52:54 -0400 Received: from eastrmmtao103.cox.net ([68.230.240.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzCEP-0000h8-61 for ram@iab.org; Fri, 15 Jun 2007 09:52:54 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070615135251.BMPQ8543.eastrmmtao103.cox.net@eastrmimpo01.cox.net> for ; Fri, 15 Jun 2007 09:52:51 -0400 Received: from [10.30.20.61] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id Bpsr1X00N0pnMhQ0000000; Fri, 15 Jun 2007 09:52:51 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <1733F2C0-324A-4C66-9904-F0B597271642@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Fri, 15 Jun 2007 09:52:51 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [RAM] DNS usage in NERD X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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, Brian Carpenter wrote: % Also, this way you remove any security issues associated with DNS, % and any confusion about IPv4 vs IPv6 connectivity to the servers. The *only* way to remove potential security issues associated with DNS is to deploy DNS Security. Period. We have huge existing risks with respect to widespread non-authentication of DNS data. NERD doesn't appear to change those existing risks. The known solution for those risks is to deploy DNS Security, which deployment apparently requires non-trivial effort but does appear to be possible. Yours, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 09:58: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 1HzCJi-0000c4-VO; Fri, 15 Jun 2007 09:58:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCJh-0000X7-BI for ram@iab.org; Fri, 15 Jun 2007 09:58:21 -0400 Received: from web58703.mail.re1.yahoo.com ([66.196.100.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HzCJf-0002Fi-2W for ram@iab.org; Fri, 15 Jun 2007 09:58:21 -0400 Received: (qmail 55522 invoked by uid 60001); 15 Jun 2007 13:58:18 -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=vqqGzJTE8kG8b5LqF29plNcuKXvZ6rUFWP/mb7TSoWdhX/Ze8akSXVTpuJI1g/g98MpwS2j5z3mhJIa85dK6/YxOmQZYeQEEiSy+Uw6OEHEb0Ap1EHN93XscsfoqkUaGHFy6f5dDwVToQJJrM7dAc0p8K8QK5dBIBRqcsAe2N1g=; X-YMail-OSG: IgbRnPcVM1mPTUFjxZr6MeYwTkdE3amGXOUR5V7GH7rmNeDOTVbsVWuw1uBV45eUS1jxgqRH_wGpxb1ajirsAj2FWdj7.BDId0QzjIorrOWTMNv_1Sjk_lSYVL7w.UBf3vEkHdb1tXrSTWyrtFWeyo.ZXw-- Received: from [24.114.255.3] by web58703.mail.re1.yahoo.com via HTTP; Fri, 15 Jun 2007 06:58:18 PDT Date: Fri, 15 Jun 2007 06:58:18 -0700 (PDT) From: Peter Sherbin Subject: Re: [RAM] Ramblings about "locator" To: Noel Chiappa , ram@iab.org In-Reply-To: <20070615125013.D2E5C86AF7@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <784410.54263.qm@web58703.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 > - Do you have to get a new one when you move? IMO that is all you need to tell a loc from an id. Thanks, Peter --- Noel Chiappa wrote: > > From: Brian E Carpenter > > > My original RAMble (sorry) ended thus: > > > Maybe the essential point is that a locator can at least in > > principle be mapped to topology and an identifier can't. > > My human-name can be mapped to a telephone number. My human-name is not, > however, a telephone number. An "identifier" can certainly be mapped to a > network location with the aid of the appropriate database, just as a DNS > name can be mapped to a network location. > > Maybe you're using the wrong word, and instead of "mapped" you really meant > something like 'directly related', or something like that, but the problem > is that that's a somewhat nebulous turn of phrase. Which is why I > previously suggested that nice gold-standard, easily-comprehendable tests > for 'does this name have location information embedded in it' are: > > - Do you have to get a new one when you move to a new location? > - Given two location-based names, can you tell, by comparing *just the > names*, whether they are 'close' to each other? > > Maybe someone else can come up with a snappy word/phrase which clearly, > cleanly and concisely embodies that very close relationship... > > > > A slightly different way to say it is that a locator is a handle for > > a route. > > No. My street address is not a handle (in any simple sense) for directions to > my house. Yes, with a lot of data (connectivity information), and a certain > amount of computing, it can be turned into directions, but the relationship is > not a simple one. > > This was all quite clear a long time ago; see IEN-19, John Shoch, > "Inter-Network Naming, Addressing, and Routing", January 1978, now finally > available at: > > ftp://ftp.isi.edu/in-notes/ien/ien19.txt > > Everyone here should be familiar with what it has to say. > > Noel > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 10:14: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 1HzCZU-0005wa-UQ; Fri, 15 Jun 2007 10:14:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCZT-0005wR-Dj for ram@iab.org; Fri, 15 Jun 2007 10:14:39 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzCZS-0006ZH-5v for ram@iab.org; Fri, 15 Jun 2007 10:14:39 -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 7204744; Fri, 15 Jun 2007 10:14:38 -0400 In-Reply-To: <46723BAD.4060307@gmail.com> References: <000901c7aef9$c3abbb90$bc92f385@nictkafle> <46723BAD.4060307@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D4FD9B7-AD59-47DC-AFC1-855819E4A8B3@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [RAM] Ramblings about "locator" Date: Fri, 15 Jun 2007 10:14:31 -0400 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ram@iab.org, Ved Kafle X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Jun 15, 2007, at 3:11 AM, Brian E Carpenter wrote: > On 2007-06-15 05:03, Ved Kafle wrote: >>> Marshall, >>> >>> ... >>>>> Maybe the essential point is that a locator can at least in >>>>> principle be mapped to topology and an identifier can't. >>>>> >>>> If in Ethernet what is essentially a random number (the MAC >>> address) >>>> becomes >>>> a locator then maybe the distinction will never be crisp. >>> Well, that horrible thought crossed my mind. I think I disagree >>> with Jarno's comment, because as soon as an Ethernet address >>> gets into a spanning tree it has become a locator (at level 2). >> So, the distinction between an identifier and a locator is >> dependent on >> the avalaibility of routing/switching infrastructure. If networks >> possess routing/switching insfrastructure based on a >> identifier namespace, the identifier simultaneously functions as a >> locator. > > My original RAMble (sorry) ended thus: > > Maybe the essential point is that a locator can at least in > principle be mapped to topology and an identifier can't. > > I think that's correct and actually consistent with much that's been > said. A slightly different way to say it is that a locator is a > handle for a route. > I think that the missing piece here is _intent_. A locator is _intended_ to be mapped to or congruent with typology. An identifier is _intended_ to be unique and independent of typology. Of course, once something is created, how it is actually used (or misused) is no longer under control, and it is safe to say, "if it can be, it will." So, you can't be crisp about usage; the goal should be to be crisp about intentions. > Brian Regards Marshall > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 10:35: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 1HzCtI-0004bq-AR; Fri, 15 Jun 2007 10:35:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCtF-0004ak-Ds for ram@iab.org; Fri, 15 Jun 2007 10:35:05 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzCtE-0002Wn-3Q for ram@iab.org; Fri, 15 Jun 2007 10:35:05 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 15 Jun 2007 07:35:03 -0700 X-IronPort-AV: i="4.16,425,1175497200"; d="scan'208"; a="165849246:sNHT40057632" 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 l5FEZ3O9022007 for ; Fri, 15 Jun 2007 07:35:03 -0700 Received: from [61.91.112.222] (sjc-vpn3-721.cisco.com [10.21.66.209]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5FEZ2tV013761 for ; Fri, 15 Jun 2007 14:35:02 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <1733F2C0-324A-4C66-9904-F0B597271642@extremenetworks.com> References: <1733F2C0-324A-4C66-9904-F0B597271642@extremenetworks.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Roland Dobbins Subject: Re: [RAM] DNS usage in NERD Date: Fri, 15 Jun 2007 07:35:03 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=581; t=1181918103; x=1182782103; c=relaxed/simple; s=sjdkim1004; 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]=20DNS=20usage=20in=20NERD |Sender:=20; bh=pR2xwpVnptSw4ABEM+Jisu6BxvIXrCAvoj9Xqf7fW2U=; b=sxQ8hFPdHPnIZVEf2Jxuu2sLCg4fIHD/mPPmHuXmhDF4QzCQ/Fx34uDp5Z8YG7Wh8sRypCz2 O4IAaK/fhZMA6zW6whTw6HUVS6oDv+mNI44GIeEbDMedR+WCgGUqtBO/oFYXPAtoTsTCo31iXD tHZrDjIMKj2UMphV0YCBzfHvw=; Authentication-Results: sj-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 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 Jun 15, 2007, at 6:52 AM, RJ Atkinson wrote: > The *only* way to remove potential security issues associated > with DNS is to deploy DNS Security. Period. There's hardly consensus within the operational community surrounding =20= the utility of DNSSEC, if that's what you're referring to, so =20 assertions of this nature aren't really supportable. ---------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Equo ne credite, Teucri. -- Laoco=F6n _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 15 17:24: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 1HzJHB-0000hZ-Bp; Fri, 15 Jun 2007 17:24:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJHA-0000gu-F7 for ram@iab.org; Fri, 15 Jun 2007 17:24:12 -0400 Received: from eastrmmtao103.cox.net ([68.230.240.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzJH9-0000AH-6X for ram@iab.org; Fri, 15 Jun 2007 17:24:12 -0400 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20070615212411.PWNF8543.eastrmmtao103.cox.net@eastrmimpo01.cox.net> for ; Fri, 15 Jun 2007 17:24:11 -0400 Received: from [10.30.20.61] ([68.10.118.38]) by eastrmimpo01.cox.net with bizsmtp id BxQA1X0080pnMhQ0000000; Fri, 15 Jun 2007 17:24:10 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Fri, 15 Jun 2007 17:24:09 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.6 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [RAM] (no subject) X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Jun 15, 2007, at 6:52 AM, RJ Atkinson wrote: >The *only* way to remove potential security issues associated >with DNS is to deploy DNS Security. Period. Later, Roland Dobbins at cisco wrote: % There's hardly consensus within the operational community % surrounding the utility of DNSSEC, if that's what you're % referring to, so assertions of this nature aren't really % supportable. Actually, the assertion is provable. DNSsec is the *only* mechanism available to provide cryptographic authentication of DNS responses. If someone wants to propose something else, that is fine, but until some alternative mechanism is defined and agreed upon then it really is the only option available. I realise that moving from the current totally un-authenticated DNS to one where DNS is authenticated is far from being a trivial exercise. There is some operational pain in making that transition. I do know of a few organisations that have made that transition successfully, not many, but there are some. Even one deployment would be an existence proof and there are more than one (not many, admittedly). So it is possible, although not painless. (And I'm not discounting the pain. :-( However, there is no other credible proposal on the table for providing strong authentication to DNS responses. And the threats are real (and have been seen in the wild). Further, those threats and vulnerabilities do apply to the current deployed IPv4 Internet. So my claim was carefully phrased. I didn't say DNSsec was easy or trivial to deploy. I said it was the only way to remove those security issues -- and my claim is indisputably true at present. Maybe later pixie dust will appear and come up with some other mechanism; I'm not aware of anything else today that can address the DNS security issues. And if this exchange motivates someone here to come up with something better than the IETF DNSsec standards, that isn't a bad outcome either. :-) Cheers, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jun 16 05:54: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 1HzUyj-0008Os-PK; Sat, 16 Jun 2007 05:53:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzUyi-0008Oa-6b for ram@iab.org; Sat, 16 Jun 2007 05:53:56 -0400 Received: from ns2.nict.go.jp ([133.243.3.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzUyg-0001l2-Hh for ram@iab.org; Sat, 16 Jun 2007 05:53:56 -0400 Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns2.nict.go.jp with ESMTP id l5G9rkO1029048; Sat, 16 Jun 2007 18:53:46 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id l5G9rk2M028453; Sat, 16 Jun 2007 18:53:46 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id l5G9rjqp028450; Sat, 16 Jun 2007 18:53:45 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id B6DEA6E46; Sat, 16 Jun 2007 18:53:45 +0900 (JST) Received: from kaflepc (ssh.nict.go.jp [133.243.3.49]) by mail2.nict.go.jp (Postfix) with ESMTP id 8147B6E40; Sat, 16 Jun 2007 18:53:45 +0900 (JST) From: "Ved Kafle" To: "'Robin Whittle'" , "'Christian Vogt'" Subject: Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels Date: Sat, 16 Jun 2007 18:53:46 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcevIB8pwTXoisvkSCiNfbMolPF06QA1lBsg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-Id: <20070616095345.8147B6E40@mail2.nict.go.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 > > Robin, > > is it correct to say that ViP anchors an access (or edge) network's > prefix at the V-router somewhere within the DFZ? > > In this case, I would see a difference between ViP and LISP > in terms of > responsibilities: > > - In ViP, it is the responsibility of the destination access network > to set up (or subscribe to) the anchor router for its prefix. > > - LISP relies on a router in (or at the border of) the source access > network to perform this functionality. > > This ViP concept reminds me of Mobile IP (v4 or v6), where a > mobile host > anchors its home network prefix with a home agent, the > location of which > is independent of the peer that the mobile host communicates > with. Both > ViP and Mobile IP use tunneling between the anchor and the > destination. > > In fact, ViP is a proposal for network mobility. It enables an access > network to change ISPs (which is nothing else but a topological > "movement") without losing reachability via the original prefix. To me, the ViP approach looks similar to the network mobility (nemo) support approach being discussed in the IETF nemo WG. In nemo, the mobile router's home agent advertises the mobile network prefix such that the packets sent by a correspondent node to an address belonging to the nemo prefix go to the home network of the moible network, where the home agent tunnels them to the current location of the mobile router. The mobile router decapsulates and forwards the packets to the addressed node. Analogy: (1) ViP routers are similar to the mobile network home agents, except that the home agents are confined to home networks where as Vip routers may be distributed in the Internet. If we suppose that home agents can be distributed like ViP routers, then these two apporaches are exactly the same. (2) ViP's ETRs are similar to nemo mobile routers, which update ViP routers (home agent) with the tunnel-end addresses. (3) In nemo, a bidirectional tunnel is set up to avoid packet filtering at border routers. Whereas in ViP, it is assumed that the BRs forward packets with ViP-mapped addresses. There are some well known problems associated with such achor point-based approaches, such as increased packet delivery delay, non-optimal routing, tunneling overhead, possibilities of single point of faiture, etc. To avoid these problems, route optimization mechanisms are being investigated in the nemo WG. Shouldn't we look for the ID-loc split solutions that avoid such problems as much as possible? Ved > > Interesting... > > - Christian > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jun 16 07:47: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 1HzWkj-00075L-LK; Sat, 16 Jun 2007 07:47:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzWki-00075G-KI for ram@iab.org; Sat, 16 Jun 2007 07:47:36 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzWkh-0004kl-Ai for ram@iab.org; Sat, 16 Jun 2007 07:47:36 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2007 13:47:30 +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 l5GBlUDe000661; Sat, 16 Jun 2007 13:47:30 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp345.cisco.com [10.61.65.89]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5GBlNDR028907; Sat, 16 Jun 2007 11:47:24 GMT Message-ID: <4673CDCB.4050805@cisco.com> Date: Sat, 16 Jun 2007 12:47:23 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Roland Dobbins Subject: Re: [RAM] DNS usage in NERD References: <1733F2C0-324A-4C66-9904-F0B597271642@extremenetworks.com> 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=763; t=1181994450; x=1182858450; 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]=20DNS=20usage=20in=20NERD |Sender:=20; bh=5+xVy44HiVjmjExhO+zlStFo4hfuh0ZJhW8pzCjYHyY=; b=RXDU68Bi0cbSMJIjmXx7TQqGSUeK0k4VEXwV5RNtAWZprTPT2igvLbqCGH1UtsE+m8uf3aKK fMrtFYve58tU8rwrfm2OYXQmCGlYk2DV1g129wOdBDitNk58882i7DdD; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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, Ran, >> The *only* way to remove potential security issues associated >> with DNS is to deploy DNS Security. Period. > > There's hardly consensus within the operational community surrounding > the utility of DNSSEC, if that's what you're referring to, so > assertions of this nature aren't really supportable. Obviously you're both right. The way I see it, when we start to see real exploits we *probably* have a way to get around them, and operators might become more motivated to implement DNSSEC (regardless of whether NERD is deployed). But in this case, I would think the risk is limited to that of a denial of service, because the database and updates are signed. Perhaps a few words are in order in the draft? Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jun 16 07:55: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 1HzWry-0000Ph-NJ; Sat, 16 Jun 2007 07:55:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzWrx-0000Pa-I0 for ram@iab.org; Sat, 16 Jun 2007 07:55:05 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzWrf-0006Sj-1K for ram@iab.org; Sat, 16 Jun 2007 07:55:05 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id ACFFA59DDD; Sat, 16 Jun 2007 21:54:40 +1000 (EST) Message-ID: <4673CF77.5040800@firstpr.com.au> Date: Sat, 16 Jun 2007 21:54:31 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: da38be4a423a556a4dcef9ca1fb76a0f Cc: Christian Vogt Subject: [RAM] Ivip (was ViP ...) X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 this is so long. I figure one long message is better than many short ones. Below I respond to questions raised by Dino and Christian in "ViP: Anycast ITRs in the DFZ & mobile tunnels". I will reply to Ved about NEMO in a separate message. I am now calling this proposal Ivip, for reasons given below. I am developing this proposal by thinking out loud on this list, because my first proposal (SRAM mapping of the FIB) was a lot of work in isolation and turned out not to be directed at the most important problem. The easiest way to get the feel of what I intend Ivip or LISP to do is to imagine this as a plumbing problem. Despite whatever improvements might be made to BGP, it seems we have to accept that the Internet can only have about X many "pipes" (divisions of the address space) by which the BGP routing system can physically move packets to border routers. The current value of X is above 200,000 and we are hoping it won't grow to much more than double this for a decade or two. But natural growth would see it double in a few years. I think the task is to provide millions of end-users - ideally tens or hundreds of millions of end-users, including companies, schools and SOHO people - with the same experience as if they had their own portable "pipe" they could take to various ISPs. For multihoming, they need two links to two ISPs, and they need to switch the Internet's pipe for their address, or subnet of addresses, from one ISP to another. So we need a system which makes a 300,000 (relatively fixed) pipe system behave much as if it had millions or tens of millions of more flexible pipes. Both LISP and Ivip do this by putting multi-pipe receptors (ETRs) in the edge networks, either at border routers or inside the edge networks. Both LISP and Ivip have a central system determining how the pipe endpoints are pointed to the ETRs. The difference is that the pipe's inputs with LISP must be inside or at the border of the edge networks of the sending hosts, while for Ivip, they can be either at the border routers of those edge networks or anywhere else in the Net. Ideally, Ivip ITR functions are performed at border routers or at transit routers close to the border routers of the sending hosts. But maybe it doesn't matter where the ITR is, as long as the total path length is not much longer than would be the case without having to pass through an ITR. (It would be technically possible to put Ivip's ITRs inside edge networks, or even do the encapsulation in the sending host - but I don't see much point in either of these approaches. Encapsulation in the sending host would make a mess if the host was behind NAT.) I think part of the difficulty in this discussion is that my idea of what LISP and Ivip (or any similar solution) can and should do is rather different from some other people's ideas - or at least from Dino's. Maybe Dino and others see LISP or whatever as being used primarily by existing AS-end users to handle whole subnets such as /20, /24 etc. with each such subnet being tunnelled to one ETR. I think of this as a "Bring Your Own PI address space" plan. I see LISP or Ivip as providing "effectively PI" addresses in much smaller chunks than BGP can handle, including especially individual IP addresses, to millions of customers who need multihoming and perhaps portability. The vast majority of those customers would never get an ASN or want to know about BGP. I see this as a way of making much better use of scarce IPv4 space, which hopefully will leave more space for new ISPs and for the larger AS-end-users who would be best served with their own PI space and current BGP approaches to multihoming and portability. I discuss this in answer to Dino's questions below. - Robin I have renamed this proposal Ivip (pr: eye-vip), though maybe "IVip" or "IViP" would be better: Internet Vastly Improved Plumbing Internet Versatile redIrection of Packets Internet Versatile indirection Protocol Initiative to Virtualise IP addresses . . . etc. This is a short acronym which is not particularly widely used, and a quick search didn't reveal any use with this capitalisation. "iViP" won't do, because it looks too cute and commercial, like "iPod" - and the Internet richly deserves its capital "I". "Vastly improved Plumbing" is probably easiest way to understand what I am trying to achieve. I think the same thing can be achieved with LISP, but LISP requires that the ITRs be either internal or border routers. Ivip's ITRs can be internal routers, border routers or transit routers. (Theoretically, the Ivip ITR function could be performed in an isolated router just for this purpose with a single connection to any transit router.) The primary benefit of Ivip over LISP (not counting Ivip's mobile tunnel idea) is that it should be easy to incrementally deploy. With LISP, any recipient host which uses a LISP EID as its address will only be reachable from sending hosts located in edge networks which have upgraded their border routers and/or internal routers to perform the ITR function. This is because LISP EIDs are IP addresses which do not match a BGP-advertised prefix. Ivip is a lot like LISP, but when a sending host sends a packet to what I call an "Ivip-mapped IP address", the packet will be delivered even if the sending host's edge network has not altered its routers in any way. The encapsulation will be performed by an Ivip ITR (Ingress Tunnel Router) somewhere in the "core". This is most likely to be a transit router which also performs Ivip ITR functions. I think that there are different conceptions of what LISP can or should do - for instance I think my understanding of LISP's power and scope is more expansive than Dino's. Not counting the mobile tunnel idea, my conception of LISP's power and scope to provide portable IP addresses, multihoming and maybe traffic engineering is just as high as for Ivip. I think Ivip's major advantage is that it could be happily incrementally deployed - even as a paid for service - whereas I think there is a major chicken-and-egg problem with incrementally deploying LISP. Below, I try to explain my conception of how LISP and Ivip would best be used to achieve the major goals (multihoming, portability and Traffic Engineering - TE) of those who use IP addresses, while minimising the growth of the "global BGP routing table". Let's say there was what I will call a "master subnet" which was "LISP-mapped" or "Ivip-mapped": 22.22.0.0/16 . The entire LISP or Ivip system would probably handle multiple such "master subnets". Most of these "master subnets" would hopefully be bigger (shorter prefixes) than this for Ivip, because I intend Ivip to minimise the number of new BGP advertisements while having as much address space as possible to split up and assign to different customers. In both LISP and Ivip, any packet sent to an address in this range: 22.22.0.0 to 22.22.255.255 will only be delivered to its proper destination if it is encapsulated by an ITR, sent to the correct ETR and then decapsulated and locally routed to the destination host. For both LISP and Ivip, the ETR must: 1 - Have an IP address which can be reached directly via the current BGP routing system. 2 - Must be located in the edge network of the receiving host - either as a border router or an internal router. 3 - Must connect to a part of the internal network which is able to forward the decapsulated packet to the receiving host. (It is also possible for the receiving host to do its own decapsulation, although this probably achieves nothing useful other than potential multihoming and TE, since the host needs a normal BPG address to be able to do this.) Now, for either LISP or Ivip I will consider different ways the central database could direct packets addressed to this "master subnet" to be handled by the ITR. Mode 1 - Tunnel packets addressed to the entire subnet to a single ETR. Mode 2 - Split the subnet into two or more smaller subnets, with packets addressed to each smaller subnet being tunnelled to different ETRs in the same edge network. Mode 3 - Split the subnet into 2 to 10 smaller subnets, with packets addressed to each smaller subnet being tunnelled to ETRs in different edge networks. Mode 4 - As for (3) but split the subnet into hundred or thousands of much smaller subnets, including individual IP addresses, and tunnel packets addressed to these subnets to ETRs in hundreds or thousands of different edge networks. As I understand it, Modes 1 and 2 provide no substantial benefit in terms of reducing the growth of the global BGP routing table. There may be some benefits in multihoming or portability of numbers (making these mapped numbers usable no matter which ISP the ETR and receiving hosts are located in). With LISP, each initial "master subnet" does not produce any burden on the global BGP routing table, whereas with Ivip, each one does present a burden, since it is advertised in BGP. With Ivip - and the proposal's viability rests on this being possible - there are (ideally) thousands of Ivip ITRs in the "core" of the Net, each advertising this "master subnet" or as many "master subnets" as there are in the entire Ivip system. No matter where a sending host sends the packet from, if the packet is addressed to one of these "master subnets" it will soon be forwarded to one of these Ivip ITRs and tunnelled to the proper ETR. I intend that the "master subnets" which are "Ivip-mapped" be generally large, such as tens of thousands of IP addresses. An extreme case would to dedicate one or more /8s to Ivip. (If this was done, there could still be load balancing between multiple ITRs in the same location, by each advertising a portion of this.) I intend that each such "master subnet" be split into *many* smaller sections, including single IP addresses, as for Mode 4 above. Let's say the Internet has the following characteristics: 10,000 ISPs, with a total of 100,000 border routers, most of them multihomed, advertising a total of 200,000 prefixes. Most of these prefixes are shorter than /24, because ISPs are generally interested in large slabs of address space so they can connect lots of customers. 10,000 "AS-end-users", meaning companies, non-profit organisations, universities, government bodies and a few keen individuals - not ISPs. These have 50,000 border routers, most of them multihomed, and they advertise 100,000 prefixes. Many of them advertise a single /24 on one or the other of their links, even though they only need one or a few IP addresses. For simplicity I am discussing only IPv4 addresses and am ignoring 3G mobile carriers who probably want huge slabs of IP addresses for their hundreds of millions of handsets. (They may want IPv6 to fit in with the Mobile Multimedia Subsystem.) Let's say these ISPs and AS-end-users are quite happy with their current situation, although their needs generally grow, which places upwards pressure on the size (300,000) of the global BGP routing table. That growth is part of the problem, but the major problems in IPv4 routing and addressing are: 1 - The shortage of fresh IPv4 addresses due to the need to assign them in largish chunks, including in the forlorn hope of maximising route aggregation. Also due to the /24 limit on BGP advertisements which means 256 long subnets are assigned to many AS-end-users when they would be quite happy with a handful of addresses, if there was some other way of achieving multihoming, portability and maybe TE. 2 - The desire and need for new ISPs to connect their border routers and to gain new, large, slabs of IPv4 space which they will split up into still-largish subnets and advertise on BGP. These new ISPs, over the next decade or two, number in the thousands or tens of thousands. 3 - The hundreds of thousands, millions and potentially tens of millions of large, medium and especially small end-users who want and need multihoming, ideally would like IP address portability, and who may want some TE capabilities. Without a new routing and addressing architecture, these will be either forced to become AS-end-users and further burden the global BGP system with routers and advertised prefixes, or will have to put up with single-point of failure links to an ISP, using non-portable IP addresses from that ISP. I see LISP and Ivip as equally applicable to solving these problems - with the small caveat that Ivip does add a little further to size of the global BGP routing table for each "master subnet" the system handles. I intend that Ivip work with a relatively small number of "master subnets" - a few to at most several hundred. However, it is possible that after 2011, it will make sense to grab sizable chunks of IPv4 address space from whoever it is currently assigned to, when that space is either not being used or is being used so lightly that this cannot be justified while so many other ISPs or end-users need the space and will be able (via LISP or Ivip) to use it very efficiently. "Efficiently", to me, means that the majority of addresses are used by a host or a router. I foresee the primary benefit of LISP or Ivip being the ability to give an end-user a single IP address, or a small subnet such as four to 16 addresses, which closely matches their immediate and near-future needs, where those addresses will be: a - Portable and usable via any ISP connection, as long as the ISP has an ETR (or as many ETRs are as needed to support such customers). b - Multihomed to a certain extent with a single upstream link to the ISP, assuming the ISP is multihomed. However this is not full multihoming. c - Capable of being truly multihomed, if the end-user has two or more links to ISPs which have ETRs. Then, the end-user (or some automated fault sensing centralised control system) will control the central LISP/Ivip database to tunnel packets to whichever ISP's ETRs it desires. d - Capable of some degree of TE, such load balancing by having some of the end-user's IP addresses using one ISP's ETR and the others using the ETR of one or more other ISPs. With a successful LISP system a single, unified Ivip system or even multiple, independent Ivip systems (assuming the Ivip systems all use relatively large "master subnets"), then provided all these approaches divide their spaces down very finely, including to individual addresses, this enables the Internet to cope with problem 3 above, very nicely, without any of those new end-users needing to become Autonomous Systems, have BGP border routers, clutter the global routing table with their /24s or waste precious IPv4 space with those 256 long subnets when they probably only want one or a handful of IP addresses. (I am assuming widespread or ubiquitous NAT adoption for IPv4. Maybe if IPv4 had always been flat-routed to individual IP address granularity we could have used the space efficiently and avoided the address shortage and therefore the evils of NAT, but I can't see how the IPv4 Internet will ever be substantially free of it.) Problem (2) is not altered directly by LISP or Ivip. However, it is made easier to solve if LISP or Ivip largely or completely handles the vast number of end-users who need multihoming, portability etc. As long as LISP or Ivip divide their subnets up very finely, then this is the best possible contribution which can be made to solving the address shortage problem (1). Over time, I foresee Ivip or something similar being used to efficiently use more and more of the currently assigned address space. All this reduces pressure on the supply of fresh space. In principle, if LISP or Ivip had been implemented from the inception of the Internet, then the BGP routing system might only cover a small subset of the available space. The whole system could have been engineered with a maximum number of advertised prefixes, a maximum number of border routers - and therefore a maximum (and hopefully high) number of ISPs, or at least ISP sites. Then, most of the rest of the address space could be handled with LISP or Ivip. This raises difficult practical questions of how the ITR, for either LISP or Ivip, efficiently handles hundreds of millions or even billions of divisions of the address space for different tunnelling treatment. I am thinking of ASIC and RAM-based techniques optimised for such lookups - which is one reason I am attracted to the idea of the ITR function being performed by a smaller number of the most advanced routers, such as transit routers (Ivip), rather than a larger number of less advanced routers in edge networks (LISP). If LISP was successful at individually mapping the IP addresses and small subnets of millions of multihoming, portable IP address desiring end-users, the requirements on each ITR's FIB would be really onerous - and performing the functions in the router's CPU would lead to really poor performance. I hope the above description conveys my vision of Ivip (or LISP) vastly improving the plumbing of the Internet. Either should be able to achieve, for end-users, the appearance of millions of flexible "pipes", when in fact the BGP routing system only provides a few hundred thousand physical pipes. Christian Vogt wrote in message 01524 (with ViP changed to Ivip): > is it correct to say that ViP anchors an access (or edge) > network's prefix at the V-router somewhere within the DFZ? If Ivip was used in modes (1) or (2) above, where an entire isolated prefix of Ivip-mapped address space (for instance bounded by BGP advertised prefixes above and below) had packets addressed to this range tunnelled always to the one edge network, then the answer may be "yes". However, like LISP, there are many such ITRs and the destination address (EID for LISP) would be accessible by tunnelling from any of those ITRs. A LISP ITR which was also a multihomed border router would be in the DFZ. I will try to avoid the distracting term "V-router". There would be many Ivip ITRs and as I wrote above. I think a single largish "master subnet" like 22.22.0.0 to 22.22.255.255 should be split into hundreds or thousands of separate mappings, to serve hundreds or thousands of users. Generally those users would connect by hundreds or perhaps thousands of ISPs, but it would be technically possible to have all those end-users accessing the Net via a single ISP. At least each one could move to another ISP which also had one or more ETRs and take their IP address with them. So generally I see each "master subnet" in LISP or Ivip being used to direct packets to hundreds or thousands of separate edge networks. Generally I think the best place for Ivip ITRs is at border routers (single and multihomed) or in transit routers, so my initial mention of ITRs in the DFZ was too loose, since single-homed border routers are not in the DFZ. Ivip ITRs could also be internal routers in the sending-host's edge network. They would grab the raw packets before they got to the border router or out past the border router. This could be a way of removing some or all of the load of ITR work from the border routers, which already have a huge number of prefixes in their FIBs. (Assuming they are multihomed, with the full BGP set, plus all the prefixes in the local network of telco carriers, ISPs and large corporations etc.) Whether a LISP or Ivip ITR uses push (has the complete database at all times) or pull (has to query, learning not to query about prefixes for which it recently got a "not mapped" response), the FIB function has a lot of work to do and a large amount of data to store. My current feeling is that this can and should be done by a smaller number of really advanced routers, such as the CRS-1, with lots of memory and flexible dedicated CPUs (188 32 bit CPUs on a single ASIC, the world's largest) - rather than on a larger number of smaller ones. > In this case, I would see a difference between Ivip and LISP > in terms of responsibilities: > > - In Ivip, it is the responsibility of the destination access > network to set up (or subscribe to) the anchor router for its > prefix. > > - LISP relies on a router in (or at the border of) the source > access network to perform this functionality. Ivip, in principle, could work with a single ITR (which I think is what you mean by "anchor router") which is accessible via BGP. However all traffic would have to be encapsulated by that single router, so I suggest there be thousands of ITRs all over the world, at border routers or close to border routers. The way I am explaining Ivip is as a single, global, system with a single centralised database which all ITRs have an up-to-date version of. This requires a push system, I guess, or some fancy continuous "pull" system. Ivip or LISP could work with a partial database, with a "pull" system querying a central or distributed system whenever a packet arrives with an unfamiliar IP address, but that is very messy, has inherent delays, and still requires a fancy FIB function and a lot of data storage. There could be multiple Ivip systems all operating independently. For instance, if I had an ASN and had a prefix assigned to me, I could set up a bunch of ITRs linked to a central database. Then, as long as at least some ISPs had a suitable ETR (which only has to strip the IP-in-IP header off a packet which is addressed to one if its IP addresses) then I could rent out individual IP addresses or subnets from my assignment, to any customer who was happy to use one of the ETR capable ISPs. (The ISP would need to configure their routers to handle the IP addresses I assign to those end-users.) This would be the RW Ivip network - so any customer of mine (someone I rented one or more IP addresses to) moved to another ISP, they would need to tell my system the IP address of the ETR in their new ISP. I think this means roughly what you wrote: "set up (or subscribe to) the anchor router for its prefix.". > This ViP concept reminds me of Mobile IP (v4 or v6), where > a mobile host anchors its home network prefix with a home > agent, the location of which is independent of the peer that > the mobile host communicates with. Both ViP and Mobile IP > use tunneling between the anchor and the destination. Yes, but Mobile IP, as I understand it and with the Ivip-mobile (ViP-mobile) as I described in: http://www1.ietf.org/mail-archive/web/ram/current/msg01518.html there is a two-way encrypted tunnel (or maybe two or more such tunnels at the same time using different IP addresses, different links via different ISPs etc.) between the mobile device and a single "anchor router". My Ivip-mobile idea is like this, assuming there are multiple hosts H1 to H4 with ordinary BGP-routable IP addresses sending packets to the one mobile device. There are various ordinary Border Routers (BR) Transit Routers (TR) shown for realism. The ITRs are either border routers or transit routers. ITR1 H1---(BR)---------(TR)-\ / \ H2--/ (TR)-\ / \ / \ Translating / \ Tunnel Router ITR2 / \ H3---(BR)----(TR)---/ (TTR)~~~~~(TR)~~~~(BR)~~~(NAT)~~(MH) \ / H4---(RR)-------(TR)------------/ H1 and H2 send raw packets to ITR1, which is the border router of their edge network. ITR1 tunnels the packets to the TTR using IP-in-IP encapsulation. LISP could do this too. H3's and H4's packets leave their edge networks. (This could not happen with LISP, because they are not addressed to a prefix which is advertised in BGP.) These packets are forwarded by the BGP routing system to the nearest router which advertises the prefix they match. For H3 and H4, this is the transit router ITR2. ITR2 does the same as ITR1 - tunnels the packets to the TTR. If this was Ivip-basic, both ITRs would tunnel the packets to the ETR inside the edge network where the receiving host resides. In principle, I guess the TTR could be a border or perhaps an internal router, but it makes most sense if it is either a transit router, or at least in the core of the Internet. In practice, there would be many TTRs, all over the world. The Mobile Host (MH) would somehow create an encrypted two-way tunnel to a TTR which was close or closest to its current location. That is a totally separate tunnel, shown as ~~~~~. It is initiated by the MH, as a VPN tunnel. As such, it doesn't matter if the MH is behind one or more NATs. It would also be able to create this tunnel to the chosen TTR if its current connection to the Net was via Ivip-basic, but lets not try to think about that now! With Ivip-basic, as per the diagram in my first message 01518, the system only handles packets from left-to right. Packets in the return direction use ordinary BGP routing, assuming the host on the left has an ordinary BGP-advertised IP address. With this Ivip-mobile scenario, packets going back from the MH to any of the H1 to H4 hosts, first travel in the encrypted VPN tunnel to the TTR. The TTR then extracts those packets and throws them into the ordinary BGP routing system. Since all hosts H1 to H4 have ordinary IP addresses, the packets travel by normal means to them. The TTR needs to check the packets it extracts and forwards, for instance to check the source address is as expected, to prevent spoofing. If there was an H5, which used an Ivip-basic-mapped IP address, there are two ways the TTR could send packets to it. Firstly, it could place the packets into the ordinary BGP routing system, in which case they would soon find themselves being encapsulated at an ITR and tunnelled to H5's ETR. Secondly, the TTR could perform the ITR function itself: encapsulating the packet with IP-in-IP, and then letting the main BGP routing system transport it to H5's ETR. If there was an H6, which used Ivip-mobile, the same two approaches could be used. H6's ETR is actually a TTR, presumably different from the TTR in the diagram above. A TTR would also have to handle packets between two mobile hosts which have tunnels to it. I guess these mobile services are going to be a commercial service since I can't imagine anyone running routers in the middle of the Net like this for free. I think a mobile host should be able to set up a second tunnel to a different TTR, or perhaps a second tunnel via a different edge network to the same TTR. In the latter case, the TTR can decide which tunnel to use, depending on some handshake or whatever to see which one works best, or at all. Ideally, if the one mobile host had two tunnels via two separate ISP's networks (such as a 3G link and a WiFi link) to two TTRs, it could switch to using the second TTR. This would require that the central database be changed so all the ITRs would tunnel (IP-in-IP) packets intended for this mobile host to the second TTR rather than the first. This is just like taking a host from one ISP to another, and changing the database to point to the new ISP's ETR. >From the point of view of an ITR, it makes no difference whether the ETR is an ordinary Ivip-basic ETR or a TTR. > In fact, ViP is a proposal for network mobility. It enables an > access network to change ISPs (which is nothing else but a > topological "movement") without losing reachability via the > original prefix. The explanations I have given were for single IP addresses - but the same principles apply to an entire prefix. Considering the whole "master subnet" or "master prefix" 22.22.0.0/16 which is one of the isolated prefixes handled by this example Ivip system, I assume that prefixes above and below this are not handled by Ivip. So to use this prefix for Ivip, it has to be advertised in BGP. If the whole prefix was not split (Mode 1 above) then it could be used as you describe, providing portability amongst ISPs for the whole prefix. This would save the end-user from having to renumber when moving to another ISP. However, it doesn't really help reduce the size of the BGP routing table, since without LISP or Ivip, this user would have got an ASN, been assigned the prefix as PI space, and advertised it in BGP. Also, with LISP or Ivip, if the end-user has two links to two ISPs and can alter the mapping database rapidly when the currently used ISP's link fails, then they have achieved multihoming. LISP generally helps reduce the size of the global BGP routing table, because no matter how small or large its "master prefixes", and no matter whether the "master prefix" is split to be mapped to multiple customers at multiple ETRs in multiple edge networks, whatever it provides is without additional BGP advertisements. (However this is on the assumption that devoting a prefix to LISP doesn't punch a hole in a shorter prefix - longer subnet - which causes it to be advertised as two prefixes rather than one.) > Interesting... Thanks! Dino wrote, in message 01519: >> An Ivip-mapped address will be universally reachable as long >> as there is a single reachable Ivip ITR which can receive >> packets from the sending host and send encapsulated >> packets to the ETR for this address. > > When you say LISP-mapped or Ivip-mapped, it is not clear to me if > you mean "map to" or "map from". Can you please clarify? By "Ivip-mapped" I mean an IP address (or subnet/prefix) which is not handled fully by the current BGP system, but causes packets destined for this address or subnet/prefix to be tunnelled to an ETR close to the receiving host. So I mean the original address, as used by the sending host (EID for LISP) is "mapped to" the IP address of an ETR. I haven't considered multiple ETRs, load balancing etc. as you do in LISP, but that should work as for LISP. I am trying to avoid "identifier", "RLOC" etc. terminology. I would describe an IP address (or subnet/prefix) which is an EID under LISP as "LISP-mapped". Packets sent to this address or subnet or prefix are "mapped" to be tunnelled to another IP address - the RLOC - which is the address of the ETR. An "Ivip-mapped" address is not directly reachable via the ordinary BGP routing system. However, a packet addressed to an "Ivip-mapped" address will be forwarded by conventional BPG routers to the nearest Ivip ITR. If all is well, the ITR will tunnel it to the correct ETR, just as with LISP. >> 4 - Point 3 has a profound effect on how the two proposals may >> be incrementally deployed. With LISP, there is a serious >> and perhaps insurmountable barrier to anyone deciding to >> connect a host to a LISP-mapped address. The first people >> to do this will find their addresses generally unreachable >> since virtually no edge networks will have upgraded any >> of their internal or border routers to perform LISP ITR >> functions. Why should they? It is a huge investment to >> enable communications with a handful of rebels who are >> voluntarily opting out of the BGP system (albeit for the >> benefit of humanity). > > A LISP site will have to use both PI and PA addresses for some > time. However, when it uses PI addresses that *will not* be in > the core routing tables, other sites can reach them only if they > are LISP enabled. Otherwise, the non-LISP enabled sites will reach > the LISP site with PA addresses. > > So we can still reduce the size of the routing table and arguably > more-specific injection from other PA blocks. I understand from this that your transition mechanism involves each receiving host (each host with a "LISP-mapped" IP address) having two IP addresses at once: one conventional and one "LISP-mapped". I am not sure how this would be practical, unless host and operating system software in the sending host could somehow choose between two IP addresses returned by DNS, and use whichever one worked first. If that could be done, the transition mechanisms would double the number of IP addresses in use, at a time when they are in short supply. Also, as long as the receiving host was reachable without LISP, I don't see why the edge network of the sending host should invest in one or more LISP ITRs. I assume users cannot be expected to be involved in any of this. For instance I assume it is not expected that people would be asked to use wwwl.example.com if their ISP had LISP ITRs or otherwise to use www.example.com. >> I can't imagine how LISP would ever get off the ground, >> since early adopters would have extremely patchy >> connectivity. No-one would put a crucial service on a >> LISP-mapped address. Since all crucial services would >> be available on ordinary BGP-routed addresses, why should >> edge networks spend money on a new or upgraded router? > > Because they want better control over their ingress traffic flows. > They need the level of indirection to achieve this. I think TE is a minor concern compared to the demand for multihoming and portability - at least among the millions of smaller end-users I am primarily thinking of. I can't imagine anyone wanting to switch their server, site or desktop computer to an IP address which had only marginal or imperfect two-way communications with the rest of the Net in order to achieve TE, portability, multihoming or even to be paid thousands of dollars! >> ViP requires no changes in the edge network of the sender. >> It can be implemented with a single ITR on some BGP router >> somewhere in the world, and a single ETR in the edge >> network of the destination host. > > Can you explain how Ivip works with PI addresses? I think your plans for using LISP - and no-doubt the plans of others - differ considerably from mine. I will try to state my guesses about what you have in mind. Please correct me if I am wrong. I think you envisage LISP primarily serving the needs of AS-end-users and perhaps ISPs. I think this means current and future AS-end-users, most of whom primarily want multihoming and portability for their network. I think you are primarily thinking of AS-end-users who want or need thousands of IP addresses. I foresee the most important users of LISP or Ivip as being partly large end-users who may now have an AS or might otherwise be tempted to get one in the future. I figure virtually none of these people or organisations have any enthusiasm for BGP. They just want a number of IP addresses connected to the Net, with multihoming via two different links to two ISPs and/or with the ability to keep their numbers so they don't have to renumber their networks when they select another ISP. The other users, probably the most important and numerous set, are those who only need one or a few IP addresses. I guess these end-users are probably not too fussed about portability. Their networks are either small or have so few exposed IP addresses that its not too much trouble to renumber a handful of routers or hosts. I figure they primarily want multihoming via two separate links, so their businesses and organisations (their lives, with Second Life . . . ) are not literally dangling from a single piece of fibre or copper. I wonder about users who really want and need 256 or more IP addresses. Unless they are a little hosting company, I can't imagine that many end-users really need 256 IP addresses at any one site. The most likely reason I guess end-users want to get an ASN and 1024 IP addresses is so they can split them into four /24s and advertise them at each of their branch offices. It would be best if someone could provide real examples based on experience rather than my guesses about what users want. I am thinking of people running small companies, schools, hospitals, seriously Net-connected home offices etc. Most of these end-users want to run a mail server and perhaps reasonably high-volume web servers from their physical sites. I don't think LISP or Ivip helps much with new ISPs or the expansion of current ISPs. All ISPs, unless they are to become part of some second-rate sub-caste of BGP-less ISPs, need an ASN, full BGP expertise, multihomed border routers and their own slabs of address space so they can do traditional BGP-based multihoming, offer LISP/Ivip host connections etc. I am hoping that LISP / Ivip or whatever will enable large areas of address space to be very finely divided and used to meet the needs of millions of companies, schools, SOHO people etc. This will make it unnecessary for most of them to get ASN numbers and to apply for genuinely PI address space. I think you envisage a "BYO PI space" model for LISP. For both LISP and Ivip I foresee some larger entity, perhaps RIRs or perhaps ISPs or commercial operators, providing stable, large, ranges of address space for the system, and then having the system divide it finely for millions, tens or even hundreds of millions of end-users. If there were plenty of ISPs with ETRs in place, there is nothing to stop multiple ISPs or whoever else setting up their own Ivip systems now. All they need to do is have their own PI address space, set up a database and a bunch of ITRs around the net - for instance at various Internet peering exchanges or at the border routers of ISPs around the world - and they can start renting out IP addresses and subnets of addresses to anyone they like, provided those users connect to the Net with an ISP who runs an ETR and is prepared to route these packets to these customers. >> 6 - Because LISP needs to be a single system, it needs to be > > LISP needs to be a single system only when the entire network > runs on PI addresses. That won't happen for a very long time. What I meant to say is that I don't think that there could be multiple LISP systems operating at once, because each system would have to convince a huge number of ISPs all over the world to invest in, or allow the installation of, an ITR which would handle the EID to RLOC mapping of the IP addresses each system used as EIDs. Maybe there could be a tech standard for ITRs and an edge network could somehow let multiple LISP system operators control its operations - but that sounds unlikely. I could imagine multiple Ivip systems, because there is no need to install ITRs in edge networks. What would be required, as with multiple LISP system, is a tech standard for the ETRs so all systems could land their encapsulated packets in edge networks, without each edge network needing to dedicate an ETR to each specific system. If there were multiple Ivip systems, each system's ITRs would only handle packets addressed to BGP advertised prefixes which were the PI address space of that system's operators. Since these ITRs will cost money, and do work for specific end-users, I think there are arguments for multiple competing Ivip systems to be created, charging the recipient host users for their IP address space and according to traffic volumes. Such a network of ITRs could also be extended to do Ivip-mobile, which would involve a lot more resources and definitely need to be a paid-for service. Multiple Ivip systems wouldn't need to know about each other, but it would be best if they all operated on similar technical principles and could all use the same ETRs in edge networks. >> 7 - One of the primary benefit of Ivip, together with providing >> reachability from the outset without requiring sending >> edge networks to do anything, is that there would be a >> smaller number of ITRs in the system. These will tend to >> be bigger than with LISP and will have more intensive work >> to do. >> >> I am thinking of direct RAM-based lookup approaches, >> involving two or so memory cycles, to speed this operation >> in hardware. >> Perhaps one or more models of current high-end router, >> such as the CRS-1, could perform these functions nicely, >> with an extensive firmware upgrade. >> >> >> 8 - With Ivip, packets to be encapsulated reach the edge of the >> BGP system or are forwarded within it, either to a single >> ITR (if the Ivip system only has one V-router) or to one >> of multiple ITR functions in separate V-routers all of >> which have the same IP address. > > Do you actually think a few ITRs is going to handle the load of > the Internet? To start with, strictly speaking, only one is needed to make the system work. To minimise the extra travel of packets, and for the system to scale indefinitely, there would need to be hundred, thousands and then tens of thousands of ITRs. I figure this would be cheaper, more stable, and more scalable than replacing all DFZ routers with souped-up versions to handle the alternative: an ever growing BGP routing table. I figure if there is a way that existing hardware, such as the 188 CPUs per SPP chip and massive high-speed RAM of the CRS-1's ingress FIB could do the ITR functions, with little or no main CPU involvement, it would be best to have a smaller number of these around the Net, each directly "push" updated with the mapping database second-by-second, than to get the same work done by much slower software-intensive hacks in smaller routers in edge networks. Those more numerous smaller ITRs would also be more of a hassle to keep fully updated. >> Ivip uses Anycast to provide multiple redundant paths >> within the BGP system for packets to find their way to >> an ITR. Anycast is not normally used for TCP >> communications, but I am hoping it will be appropriate >> here, since the individual ITRs only encapsulate the >> packet and tunnel it to the ETR. > > I have actually tested LISP using anycast addresses and it has the > same property. If ITRs have the following mapping cached: > > {0.0.0.0/0, > 1.1.1.1, 2.2.2.2} where 1.1.1.1 and 2.2.2.2 are > anycast addresses, you can have various ITRs use the closest > ETRs based on the above locator addresses. My understanding of what you are doing here is a completely different use of anycast than what I had in mind. I was thinking of anycast as a way of making multiple BGP routers accept (or rather attract) the packets which were addressed to a prefix which needed to be handled by an ITR. So I was thinking of all those ITRs having the same IP address. Now I don't think this anycast has any purpose. All that is required is to make multiple ITRs advertise the same prefix. Is there any precedent for two or more BGP routers advertising the same prefix? From what little I know of BGP, it should work fine - but I would really appreciate a BGP expert's view of this. I understand the purpose of your use of anycast is to deliver the packets to a receiving host closest to the ITR. Since the sending host is presumably close to the ITR and the receiving host is surely close to its ETR, this provides faster responses, less traffic across the Net etc. I hadn't thought of this. I think it is a good idea. Since the ITR function of Ivip would be similar or identical to that of LISP, the same thing could be done. > In the spec we call these boxes "reencapsulating routers", where > the anycast box decapsulates and then does a lookup on the inner > DA where it has a different mapping (a list of locators where the > site actually is) to reach the site's ETR. Hmmm - this is a totally different purpose from what I guessed when writing my response above. I don't understood the need for multiple encapsulations in LISP or Ivip. Can you give an example of when this would be helpful? >> 9 - LISP and what I will call "Ivip-basic" both have their ETRs >> in edge networks, or at the border router. These ETRs must >> have an interface with an IP address which is reachable via >> the global BGP system. These only handle packets one way - >> from the sender HA to the LISP/Ivip-mapped destination >> address of HB. >> >> Packets in the return direction HA <- HB are sent normally, >> without relying on tunnelling, if the destination HA's >> address is not LISP/Ivip-mapped. Otherwise, a similar >> process occurs with the packet being intercepted by an ITR >> and tunnelled to the ETR which handles HA's address. > > This can only work if HA is using a PA address. I don't think it matters whether HA is using PI or PA addresses. As long as HA's address is part of a BGP advertised prefix which is not handled by Ivip ITRs, then the the packets to HA will flow to it as they do today, without using LISP or Ivip. I wrote this point 9 as part of a sequence of differences between LISP and Ivip, but this point only describes similarities and then a separate mobile tunnelling idea. >> Example of ViP-basic >> -------------------- >> >> ASCII Art only works with fixed width fonts: >> >> >> Edge Network A >> [ITR] >> HA---(IR)----(BR1NA)------(VR1)-----(TR2)--(TR4) Edge Network B >> \ \ \ >> \ \ \ [ETR] >> TR1)----(VR2)---(TR3)---(BR1NB)---(IR)---HB >> \ / >> \ / >> (TR5)----(TR6) >> \ >> \ Edge Network C >> \ [ETR] >> (BR1NC)----HC >> \ >> ---HD > > I don't understand the benefit of reducing the number of ITRs but > still maintaining an ETR in each site. You still have to manage > the ETRs. So the gain is not that great. I think the ETRs have a light workload and don't need any fancy database. Maybe existing routers can be programmed to look out for an IP-in-IP packet addressed to one of their IP addresses and then to simply pop off the header and treat the remaining packet as if it had just arrived. I recognise there may be more to do, perhaps regarding ITRs trying to see if the ETR considers a destination host reachable at present, and maybe things to do with transferring hop-counts to the decapsulated packet. I think ETRs are easy and could probably be generic. I don't think they need central management. ETRs only need be installed at ISPs where customers are paying for access and have chosen to use LISP/Ivip-mapped addresses. Ivip requires a suitable number of high-performance ITRs out in the Net in general, and LISP requires at least one ITR in every edge network, ISP or AS-end-user, where there is a host which wants to communicate with the host which is on a "LISP-mapped" IP address. >> HA's address is 11.11.11.11, which is part of a prefix which is >> advertised in BGP and which is not covered by Ivip mapping. >> >> HB's address is 22.22.0.1, which is part of 22.22.0.0/16, which >> is also advertised in BGP and which is Ivip-mapped. The other >> hosts' addresses are: >> >> HC = 22.22.4.1 >> HD = 22.22.4.2 > > If this is the example, why do you need ITRs or ETRs at all? If > you have routeable addresses just move the packets as we do today. > > Dino Because my intention is to split up the 65,536 addresses to be used by customers far and wide. In principle, each single IP address could be mapped to a host in a different edge network. I think your idea of how this stuff can best be used is rather different from mine. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jun 16 07:55: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 1HzWsA-0000VW-Ii; Sat, 16 Jun 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 1HzWs9-0000VQ-2u for ram@iab.org; Sat, 16 Jun 2007 07:55:17 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzWrs-0006Xh-Ne for ram@iab.org; Sat, 16 Jun 2007 07:55:17 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2007 07:55:01 -0400 X-IronPort-AV: i="4.16,429,1175486400"; d="scan'208"; a="123795593:sNHT63787252" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5GBt041020312 for ; Sat, 16 Jun 2007 07:55:00 -0400 Received: from [61.91.112.222] (rtp-vpn2-38.cisco.com [10.82.240.38]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5GBswBe021327 for ; Sat, 16 Jun 2007 11:54:59 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <4673CDCB.4050805@cisco.com> References: <1733F2C0-324A-4C66-9904-F0B597271642@extremenetworks.com> <4673CDCB.4050805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <052D3E90-4132-4CF3-83CA-3908E52DDE95@cisco.com> Content-Transfer-Encoding: quoted-printable From: Roland Dobbins Subject: Re: [RAM] DNS usage in NERD Date: Sat, 16 Jun 2007 04:55:02 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1272; t=1181994900; x=1182858900; 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]=20DNS=20usage=20in=20NERD |Sender:=20 |To:=20ram@iab.org; bh=ynnLf3VLt4EkgSOikaeR1NsA91XN0j1pKwB0nhea97w=; b=ra+boCOnnHnFLbuOEvu9MP+3VjH7Wp5VW6IFus54CjKt6XEeJ3hRqefgefOojlIHWe123YjC h6YTKl2skfyIK1w5NRGgz3/aTjcTS2PPNIX4r2+jUkaXF/XdkZ2W+pto; 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: 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 Jun 16, 2007, at 4:47 AM, Eliot Lear wrote: > The way I see it, when we start to see real exploits we *probably* =20 > have a way to get around them, and operators might become more =20 > motivated to implement DNSSEC (regardless of whether NERD is =20 > deployed). I don't want to waste bandwidth here on the reasons that many believe =20= that DNSSEC fails to solve a series of posited non-problems, but =20 suffice it to say that DNSSEC isn't universally as providing useful =20 security functionality, and furthermore, some believe it introduces =20 problems of its own. For purposes of this discussion, let's =20 stipulate that additional security mechanisms will probably be added =20 to the DNS at some point in the future, at leave it at that. > But in this case, I would think the risk is limited to that of a =20 > denial of service, because the database and updates are signed. =20 > Perhaps a few words are in order in the draft? A more thorough analysis would be useful, but that's my initial take, =20= too. ---------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Equo ne credite, Teucri. -- Laoco=F6n _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jun 16 08:05: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 1HzX1k-0004Qk-Jk; Sat, 16 Jun 2007 08:05:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzX1i-0003wC-Ml for ram@iab.org; Sat, 16 Jun 2007 08:05:10 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HzX02-0007FJ-Az for ram@iab.org; Sat, 16 Jun 2007 08:03:27 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 7E10C59DDD; Sat, 16 Jun 2007 22:03:21 +1000 (EST) Message-ID: <4673D180.3070903@firstpr.com.au> Date: Sat, 16 Jun 2007 22:03:12 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Ivip (was ViP ...) References: <4673CF77.5040800@firstpr.com.au> In-Reply-To: <4673CF77.5040800@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Christian Vogt X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 diagram in my previous email was crook. Here it is again: ITR1 H1---(BR)-------(TR)-\ / \ H2--/ (TR)-\ / \ / \ Translating / \ Tunnel Router ITR2 / \ H3---(BR)--(TR)---/ (TTR)~~(TR)~~(BR)~~(NAT)~~(MH) \ / H4---(RR)-----(TR)------------/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jun 16 17:31: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 1Hzfrw-0001WE-MF; Sat, 16 Jun 2007 17:31:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzfrv-0001W8-MB for ram@iab.org; Sat, 16 Jun 2007 17:31:39 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzfru-0004Hb-8y for ram@iab.org; Sat, 16 Jun 2007 17:31:39 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4C0A6212E66; Sun, 17 Jun 2007 00:31:36 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0EDF0212DF2; Sun, 17 Jun 2007 00:31:36 +0300 (EEST) Message-ID: <467456B7.4030902@nomadiclab.com> Date: Sun, 17 Jun 2007 00:31:35 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Ved Kafle Subject: Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels References: <20070616095345.8147B6E40@mail2.nict.go.jp> In-Reply-To: <20070616095345.8147B6E40@mail2.nict.go.jp> 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: c1c65599517f9ac32519d043c37c5336 Cc: 'Robin Whittle' , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Ved: >> In fact, ViP is a proposal for network mobility. It enables an access >> network to change ISPs (which is nothing else but a topological >> "movement") without losing reachability via the original prefix. > > To me, the ViP approach looks similar to the network mobility (nemo) support > approach being discussed in the IETF nemo WG. [...] Absolutely. This is what I was saying. > Analogy: > (1) ViP routers are similar to the mobile network home agents, except that > the home agents are confined to home networks where as Vip routers may be > distributed in the Internet. Actually, ViP routers are confined in the same way as home agents in that both can only support "home" prefixes that correspond to their topological location in the Internet. After all, the idea of ViP routers is to have them advertise sub-prefixes from their ISP's global routing prefix so that the sub-prefixes can be aggregated with the global routing prefix and do not require a separate slot in the DFZ routing table. [...] > There are some well known problems associated with such achor point-based > approaches, such as increased packet delivery delay, non-optimal routing, > tunneling overhead, possibilities of single point of faiture, etc. Right. And things don't get better if we do the indirection for all hosts, not just mobile hosts or hosts moving with mobile networks. > To avoid > these problems, route optimization mechanisms are being investigated in the > nemo WG. Shouldn't we look for the ID-loc split solutions that avoid such > problems as much as possible? Without an intention to prefer either mechanism, I just want to note that the advantage of ViP is a better transition path, whereas LISP performs better from the perspective of packet propagation latencies and fault tolerance. As a matter of fact, LISP is nothing else but route optimization (in Mobile IPv6 terms) for ViP. - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jun 17 07:48: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 1HztF7-0002DV-4C; Sun, 17 Jun 2007 07:48:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HztF5-0002DO-70 for ram@iab.org; Sun, 17 Jun 2007 07:48:27 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HztF3-0008EF-NJ for ram@iab.org; Sun, 17 Jun 2007 07:48:27 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id CA4D659E4F; Sun, 17 Jun 2007 21:48:17 +1000 (EST) Message-ID: <46751F78.6040501@firstpr.com.au> Date: Sun, 17 Jun 2007 21:48:08 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels References: <20070616095345.8147B6E40@mail2.nict.go.jp> <467456B7.4030902@nomadiclab.com> In-Reply-To: <467456B7.4030902@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: Christian Vogt , Ved Kafle X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 will reply to Christian and Ved in the thread: "Ivip (was ViP ...)". - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jun 17 07:49: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 1HztGG-0003p5-PY; Sun, 17 Jun 2007 07:49:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HztGF-0003p0-Bv for ram@iab.org; Sun, 17 Jun 2007 07:49:39 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HztGA-0000Px-1S for ram@iab.org; Sun, 17 Jun 2007 07:49:39 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 921BF59E4F; Sun, 17 Jun 2007 21:49:31 +1000 (EST) Message-ID: <46751FC2.30804@firstpr.com.au> Date: Sun, 17 Jun 2007 21:49:22 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Ivip (was ViP ...) References: <4673CF77.5040800@firstpr.com.au> <4673D180.3070903@firstpr.com.au> In-Reply-To: <4673D180.3070903@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5c4dbf5b8b26864121f8d3a6e6be1ee0 Cc: Christian Vogt , Ved Kafle X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 replying to Ved's and Christian's comments in "Re: ViP: Anycast ITRs in the DFZ & mobile tunnels", with "ViP" changed to "Ivip" (eye-vip). I apologise for the length again. It would probably not be so hard to describe Ivip to one person, face-to-face, with conversation and hand-drawn diagrams. Trying to do it for a bunch of people via email takes more words. VK> To me, the Ivip approach looks similar to the network mobility VK> (nemo) support approach being discussed in the IETF nemo WG. VK> In nemo, the mobile router's home agent advertises the mobile VK> network prefix such that the packets sent by a correspondent node VK> to an address belonging to the nemo prefix go to the home network VK> of the mobile network, where the home agent tunnels them to the VK> current location of the mobile router. The mobile router VK> decapsulates and forwards the packets to the addressed node. I threw this proposal together quickly without checking other protocols - and I don't claim it is highly original. There are two aspects to the proposal at present: "Ivip-basic" and "Ivip-mobile". Ivip-basic ---------- H1---(ITR1)---\ / \ H2-/ \ (ETR1)----RH / H3---(ITR2)----/ (ITR3) (ETR2) Sending hosts H1, H2 and H3 are assumed to have ordinary IP addresses, reachable via BGP. The ITR function is generally performed in border routers or transit routers, but can be performed in interior routers of the edge network. Packets from the Receiving Host RH flow by ordinary BGP routers back to the sending hosts. If a sending host is also using an Ivip-mapped IP address, then the same process occurs in reverse, with the packet sent by RH finding their way to the first ITR, probably at or near the border router of its edge network, and being encapsulated and sent to the ETR for the host on the left side. None of this is shown in the above diagram. ETRs are provided by ISPs, or the AS-end-users who run the edge networks. They only serve receiving hosts in those edge networks. How does the edge network know that the decapsulated packets emerging from the ETR must be sent to a particular host in its network? The ETR and the routers nearby need to be configured to look out for this IP address, or the Ivip-mapped subnet, and route it internally to the receiving host. With Ivip, these packets are addressed to a prefix (a large subnet I call the "master-subnet") which is advertised in BGP. With LISP, they are not. To support either LISP-mapped or Ivip-mapped IP addresses, the edge network needs not only an ETR to decapsulate the packets, but it needs a routing rule specific for that IP address or subnet which directs packets addressed to that address or subnet to wherever the particular host is located. This is probably a non-trivial task for an edge network, but the are being paid by their customer with the host which uses LISP-mapped or Ivip-mapped addresses. Assuming a single global Ivip system, the ITRs may be provided by various operators, but work as a single system, without any constraints on whose packets they will encapsulate. What may be unique about Ivip is that these ITRs are numerous and located (usually) at border or transit routers where any sender's packets will eventually be sent to one. What may also be unique is the idea that all these ITRs advertise the same set of prefixes: whatever "master prefixes" the Ivip system handles. Generally, these "master prefixes" are split into many smaller sections, each with a different mapping to an ETR. This works fine down to individual IP addresses. There needs to be a single central system for controlling the mapping - and every ITR has an up-to-date copy of this database. Ivip-basic is a one-way, public, system. Ideally it would be provided for free, but there probably needs to be some fees for running the ITRs and administering the database. These could be paid for by the Ivip "customers" - those individuals and organisations etc. who pay for one or more IP addresses in the system. As shown above, the ETRs are in the edge network in which RHs are located or connected to. Each RH in this depiction has a single link to its ETR, but an RH could easily have links to two ETRs, especially in two edge networks, to achieve multihoming. Ivip-mobile ----------- Ivip-mobile is an extension of the above, but would probably always be a commercial service. There could be any number of Ivip-mobile operators. Each would have a set of special ETRs called TTRs (Translating Tunnel Routers). These TTRs are in general either at border routers or more likely amongst the transit routers. TTRs could also be in edge networks. H1---(ITR1)---\ / \ H2-/ \ (TTR1)~~~~~~~~MH / / H3---(ITR2)----/ / / (ITR3) (TTR2)~~~~/ The Mobile Host (MH) could be behind NAT and always establishes an encrypted 2-way tunnel to at least one TTR. (I am assuming an encrypted and compressed 2-way VPN-like tunnel, but I guess it could also be done by simple two-way IP-in-IP tunnelling.) The Mobile Host may establish tunnels to multiple TTRs, including using completely different links, such as ADSL and GPRS radio. The Ivip system maps the MH's IP address (or prefix) to one of the TTRs, so all the encapsulated packets from the world's ITRs arrive at that TTR. Some central monitoring system could detect that one TTR is dead, or that its link to the MH is dead, and then the mapping could be changed to the other active TTR. To the Ivip system, which is really the ITRs and their controlling database, there is probably no way of telling whether the currently mapped-to IP address points to an ETR which is for Ivip-basic (meaning the RH is in an edge network and the ETR is a border or internal router of that edge network, with packets flowing back independently of these arrangements) or whether the mapped-to IP address points to a TTR. A TTR is simply an ETR which the MH tunnels to, and which therefore also acts like the MH because this TTR is where the MH's outgoing packets are first let loose on the Net. With mobile-IPv6 (as I understand it), there is exactly one router which the MH tunnels to - it is the router which runs the LAN in which the MH's home address is located. Mobile-IPv6 can also cause corresponding hosts (H1 to H3 etc.) to send packets to and from the MH directly, rather than using the home router. This is more efficient, but requires the corresponding host to have special mobile-IPv6 capabilities. Ivip-mobile is very different from mobile-IPv6 in that the MH can choose one or more TTRs to tunnel to. Ideally it will choose the ones which are closest to its current location. Also, there is no "home IP address" on a LAN, as there must be with mobile-IPv6. As far as I know, mobile-IPv4: http://www.mip4.org relies on a "home-router" and home IP address too. Likewise, as far as I know, NEMO does as well: http://tools.ietf.org/html/rfc3963 http://tools.ietf.org/wg/nemo/ Also, like LISP, Ivip works with single IP addresses or any number of IP addresses. I am not sure whether mobile-IPv6, mobile-IPv4 support subnets, but I guess they could do it as individual arrangements for multiple IP addresses. NEMO supports subnets. The reason a figment of our imagination like Ivip can boldly invoke a worldwide network of ITRs while mobile-IPv6/4 cannot is that now we are desperate. If we don't do something on a grand scale such as this, we will all be doomed to paying for endless upgrades to all the Internet's transit and multihomed border routers as the BGP routing table grows to 500,000, 1,000,000, 2,000,000 etc. LISP boldly invokes at least one ITR in every edge network which has a host which needs to communicate with a host or network whose IP address or subnet is handled by LISP. In practice, for LISP-mapped IP addresses to be attractive to anyone, this means most edge networks must have one or more ITRs. Ivip less boldly invokes ITR functions broadly distributed in the border routers and transit routers. I can get away with this, as can the LISP authors, because we are desperate. Both LISP and Ivip require the relatively modest ETRs to be installed in the edge network of any host which has its address or subnet handled by LISP or Ivip. Ivip could also exist as multiple independent networks of ITRs, each with its own "master-subnets" and its own central database. Since Ivip involves a bunch of souped-up routers at border router and transit router locations, it is not much more of a step to have some of these, or perhaps separate networks of routers, performing TTR functions. Each TTR system could be entirely independent of other TTR systems, and of the one or more ITR systems (provided the TTR did not also implement ITR functions). The multiple TTR systems could compete and provide commercial services to the customers who they provide Ivip-mapped address space for. Please see my previous long message where I write about my conception of Ivip or LISP, which I think is different of Dino's "BYO address space" vision for LISP. If there was a single Ivip system of ITRs, presumably the system would not be allowed to fail, so any address space it hands out via its mapping functions would be essentially "Provider Independent". If there were competing Ivip systems, then all of them, apart from perhaps one "universal public" one, would be dependent on some company, ISP etc. and be for-profit - so the IP address still depends on that company. However, in both cases, where the customer whose address is mapped by these systems chooses to attach to the Net (their choice of ISPs) is completely unrelated to the Ivip system(s). Any TTR systems could be independent of the Ivip systems. A customer could choose to use any number of competing TTR systems. They have nothing to do with IP addresses, since their TTRs are only of value to the customer if the ITRs tunnel packets to the TTRs, and since the customer pays for, or has control of, the mapping of their IP address, the customer only depends on the ITR system for the security of "tenure" of this address - and not at all on any TTR systems it uses. Each TTR could also act as an ITR for that system's "master-subnets". If there was a single, global, system of ITRs, it would be good if the privately run TTRs also acted as ITRs within the global Ivip system. Otherwise, packets would have to first find an ITR and be tunnelled to the TTR when they are going to an Ivip-mobile host. For simplicity, the following assumes there is a single set of "master-subnets" (AKA "master-prefixes") which are handled by a single Ivip system which includes an Ivip-mobile function as well. It is likely that a router which performs TTR functions will also act as an ITR. H1------(TR)------------(ETR1)------RH1 \ MH2~~~~~~(TTR1)~~~~~~~~MH1 / \ H2----(ITR1) \ / (TR) H3----/ \ \ MH3~~~~~~~~~~~(TTR2) H1 and H2 have ordinary BGP routed IP addresses. Packets sent from H1 to MH1 are received by TTR1 which acts like an ITR. Ordinarily, an ITR encapsulates the packet and tunnels it to the ETR to which the destination (MH1) IP address is mapped to. In this case, TTR1 is the destination ETR, so there is no need to encapsulate the packet. It is simply placed on the VPN 2-way tunnel ~~~~~~~~ and sent to MH1. Packets from MH1 to H1 follow the reverse path - they come out of the VPN tunnel at TTR1 and are forwarded via normal BGP routing back to H1. The same would be true between H1 and MH2. Packets from H2 to MH1 (or MH2) would be encapsulated by ITR1 and tunnelled (one way, IP-in-IP) to MH1's ETR, which is TTR1. TTR1 decapsulates them and sends them on the VPN tunnel to MH1. Packets from MH1 to H2 pop out of the VPN tunnel at TTR1 and use ordinary BGP forwarding to get to H2. RH1 has an Ivip-mapped IP address. It is not using Ivip-mobile - just Ivip-basic. In this diagram, the nearest ITR to H1 is TTR1. When H1 sends a packet to RH1, it is forwarded by the TR transit router to TTR1, and encapsulated. TTR1 sends the packet in a 1-way IP-in-IP tunnel to ETR1 (at the border of, or within an edge network), which forwards it within the edge network to RH1. Packets from RH1 must be accepted by the border router of its edge network (which could be ETR1 or some other router not shown) and are sent via ordinary BGP forwarding to H1. A packet from MH3 to MH1 goes via 2-way VPN tunnel to TTR2 where it is encapsulated and sent on a 1-way IP-in-IP tunnel to MH1's ETR, which is TTR1. This decapsulates it and sends the packet along its 2-way VPN tunnel to MH1. Packets going from MH1 to MH2 follow exactly the opposite path, with a 1-way encapsulated IP-in-IP tunnel from TTR1 to TTR2. Mobile-IPv6 doesn't assume anything about routers, except its home router. It doesn't assume anything about corresponding hosts, since ordinary hosts can simply communicate with the mobile host as if it was at its home location, with the home router tunnelling to and from the mobile host, wherever it is. Ivip doesn't assume anything about corresponding hosts, or the host whose IP address or subnet is mapped by Ivip. Ivip does assume there is a system of ITRs - ideally all around the Net at border routers and transit routers. Ivip requires the receiving host have at least one ETR. For Ivip-basic, there will be one ETR in the edge network where the receiving host is currently connected. This mapping can be switched to another ETR, for instance for multihoming. There could also be load balancing between multiple ETRs, as LISP proposes. VK> Analogy: VK> (1) Ivip routers are similar to the mobile network home agents, VK> except that the home agents are confined to home networks VK> where as Ivip routers may be distributed in the Internet. Yes, but the TTRs are similar to the home-agent. With Ivip-mobile the mobile host's IP address doesn't have a home anywhere. Packets from ordinary IP addresses are tunnelled by ITRs to the currently chosen ETR, and that ETR (in the case of a mobile host) is a TTR which the mobile host has a tunnel to. This means that wherever the mobile host is and wherever the corresponding hosts are, assuming there are plenty of ITRs and TTRs, the total path length will be the same as, or not much longer, than without Ivip. VK> If we suppose that home agents can be distributed like Ivip VK> routers, then these two approaches are exactly the same. In my perhaps faulty understanding of mobile-IPv4, mobile-IPv6 and NEMO, this could not occur, because the home-agent router needs to be connected to an edge network whose border router advertises the address range the router handles. It can't be moved somewhere else, assuming that router only handles a part of the subnet its edge network advertises, because to do so would create two or three BGP advertisements instead of one. VK> (2) Ivip's ETRs are similar to nemo mobile routers, which update VK> Ivip routers (home agent) with the tunnel-end addresses. I read the first ten pages of NEMO's RFC3963. NEMO extends mobile-IPv6 with a "mobile router". This is somewhat like a mobile-IPv6 mobile node, except it is a router which has links to the multiple mobile hosts. Also, there is no "route optimization" as in mobile-IPv6 where capable correspondent nodes can send packets directly to and from whatever IP address the mobile host (or NEMO mobile router) is currently located at. So with NEMO, all traffic to the multiple mobile nodes goes through the fixed location (I assume) home agent router, and then via a two-way tunnel to the mobile router - which can flit from one IP address to another, taking its flock of mobile nodes with it. I don't think there is much resemblance between any of these pre-existing mobile systems and either Ivip-basic or its Ivip-mobile extension. Ivip's notion of large numbers of public ITRs and TTRs (by paid-for access I guess) with the mobile host choosing which TTR to use at any time, does not seem to have a parallel in these pre-existing mobile systems, which assume a fixed home-agent router. Ivip-mobile will only be possible because there will be a global system of ITRs which tunnel packets to any BGP-reachable IP address is currently selected to act as the ETR for the mobile-host's Ivip-mapped IP address. Without that global ITR system, steering packets anywhere on the NET, the pre-existing technologies mobile-IPv4/6-NEMO must rely on all packets going to a home-agent router, except for mobile-IPv6 which can use "route-optimization" and set up smart-enough correspondent nodes to send packets directly to and from the mobile node. LISP could just as easily be extended as I suggest with Ivip-mobile. Ivip is similar to or identical to LISP, or at least some type of LISP, except that it should be easy to incrementally deploy and except that it does require all its "master-subnets" (hopefully few and large) to be advertised in BGP. VK> (3) In nemo, a bidirectional tunnel is set up to avoid packet VK> filtering at border routers. Whereas in Ivip, it is assumed VK> that the BRs forward packets with Ivip-mapped addresses. In Ivip-basic, with the receiving host semi-permanently in an edge network, I assume that the edge network's routers are programmed to allow packets from its IP address to be sent to the global BGP system. If not, then the receiving host would need to use Ivip-mobile with a TTR outside this edge network. I tend to think of the TTR function being implemented within routers which are already transit routers, or in routers which are located at peering points and are primarily connected to transit and border routers. However a TTR could be a border router or inside an edge network, as long as that border router or edge network allowed egress of the outgoing packets (which could have almost any source address) to the BGP routing system. VK> There are some well known problems associated with such anchor VK> point-based approaches, such as increased packet delivery VK> delay, non-optimal routing, tunnelling overhead, possibilities VK> of single point of failure, etc. To avoid these problems, VK> route optimization mechanisms are being investigated in the VK> nemo WG. Shouldn't we look for the ID-loc split solutions that VK> avoid such problems as much as possible? Ivip-basic isn't at all like these pre-existing mobile protocols. The Ivip-mobile extension only loosely resembles them, because there is no one fixed home agent. Altogether, Ivip-basic and Ivip-mobile should enable packets to flow without much extra distance or hops. There is still a tunnelling overhead, and perhaps problems with MTU limits. Christian Vogt quoted Ved Kafle and responded: VK> To me, the Ivip approach looks similar to the network mobility VK> (nemo) support approach being discussed in the IETF nemo WG. ... CV> CV> Absolutely. This is what I was saying. I think Ivip is very different from NEMO etc. VK> Analogy: VK> (1) Ivip routers are similar to the mobile network home agents, VK> except that the home agents are confined to home networks VK> where as Ivip routers may be distributed in the Internet. CV> CV> Actually, Ivip routers are confined in the same way as home CV> agents in that both can only support "home" prefixes that CV> correspond to their topological location in the Internet. As I explained above, and in a long message which started this thread, this is not the case. There are lots of TTRs to choose from, so ideally the mobile node will choose one close to it. This is only possible because there is a global network of ITRs, acting like a coordinated bunch of mirrors, tunnelling all the mobile node's traffic to this TTR, another TTR or wherever the mobile node (or some other control system) tells the ITRs to tunnel the packets to. CV> After all, the idea of Ivip routers is to have them advertise CV> sub-prefixes from their ISP's global routing prefix so that CV> the sub-prefixes can be aggregated with the global routing CV> prefix and do not require a separate slot in the DFZ routing CV> table. An Ivip ITR is one of many which advertises one or more "master prefixes". Each ITR attracts packets addressed to these prefixes and tunnels them off to potentially millions of different ETRs. A TTR acts like an ETR as far as the ITR system is concerned. Its just that a TTR is probably not in an edge network - and it connects to the host which has the Ivip-mapped IP address via a two-way tunnel. VK> There are some well known problems associated with such anchor VK> point-based approaches, such as increased packet delivery VK> delay, non-optimal routing, tunnelling overhead, possibilities VK> of single point of failure, etc. ... CV> CV> Right. And things don't get better if we do the indirection CV> for all hosts, not just mobile hosts or hosts moving with CV> mobile networks. Other than the central database, I don't think there is a central point of failure for Ivip-basic or its Ivip-mobile extension. Assuming the mobile host has a BGP reachable IP address, or is behind a NAT firewall which has such an address, it can set up a two-way tunnel to one or more TTRs. If one goes down, it can use another. Ideally it would use nearby ones. Ivip-basic, like LISP, relies on the receiving host having a connection to a particular ETR. LISP, Ivip-basic and Ivip-mobile all enable the receiving host to set up links to multiple ETRs and then (directly, or by some automatic system, since the receiving node could be out of contact after the failure of its active link) the ITRs can all be told to tunnel packets to whichever ETR is currently used. This is genuine multihoming, including for Ivip-mobile - if the two links to the two TTRs are by physically different networks. VK> To avoid these problems, VK> route optimization mechanisms are being investigated in the VK> nemo WG. Shouldn't we look for the ID-loc split solutions that VK> avoid such problems as much as possible? CV> Without an intention to prefer either mechanism, I just want CV> to note that the advantage of Ivip is a better transition path, CV> whereas LISP performs better from the perspective of packet CV> propagation latencies and fault tolerance. Thanks for agreeing with what I think is the most important difference - that Ivip looks like it would be easier to introduce. CV> As a matter of fact, LISP is nothing else but route CV> optimization (in Mobile IPv6 terms) for Ivip. LISP has the ITR function inside or at the border of the edge network. Ivip typically has the ITR function at the border router or amongst the transit routers. With LISP, if the ITR function is at the border router or in an internal router which is on the shortest path between the sending host and the border router, then the total path likely to be the same as for a direct packet (other than a potentially longer path in the destination edge network if the ETR isn't exactly on the shortest path to the receiving host). With Ivip, the same is true if either of the following typical conditions is true: 1 - The ITR function is at the border router of the sending edge network. 2 - The ITR function is in a transit router which is on the shortest path towards the destination edge network's border router. So Ivip's total path length would only be longer than LISP's if the ITR function was not in the sending edge network's border router but in a transit router (or perhaps another border router of another edge network) which is off the shortest path to the destination network's border router. If Ivip or some similar system is adopted, before long, any ISP or AS-end-user network with any substance would want to install the ITR function at its border routers and/or at internal routers - to reduce the processing load on the border routers. They would want to do this so their outgoing Ivip-mapped packets do not depend on anyone else's external ITRs. A fully hardware optimised ITR, with its big database and need for constant updates from the central Ivip database, could be quite expensive. But it has to be provided either by the edge network, or by some ISP or transit provider the edge-network uses for its upstream links. I am not sure how the economics would work best. Maybe for smaller ISPs and AS-end-user edge networks it would be better to pay their upstream provider to handle the ITR function. Over time, as ITR-capable hardware costs reduced, more and more smaller ISPs and AS-end-user networks would probably find it better to run their own ITR rather than pay to use their upstream provider's ITR. I think only those smaller edge-networks would not run ITRs in the long-run. The most important thing is that Ivip could start running with just a handful of ITRs somewhere in the Net. Ideally there would be multiple ITRs for each country. The only significant path-length increases with Ivip would occur when the sending edge network is nowhere near an ITR. This would occur in the early days of introduction. But once Ivip became established and a significant amount of traffic was reliant on ITRs, competition between upstream providers would cause them to ensure there were ITRs in upstream paths, rather than off to one side somewhere. There are two other situations of practical interest, in which Ivip would also produce no increase in total path length. Firstly, it is perfectly possible to install Ivip ITRs inside edge networks. Then, the situation would be identical to LISP: assuming the ITR was on the path from the sending host to the border router, there would be no extra path length. Edge networks could install internal ITRs to take the load off their border routers. However, this would slightly add to the traffic load inside the network, due to the IP-in-IP overhead. The second scenario is most likely to occur when the destination edge networks are very close or their routers are peers. If the sending edge network has no ITR, the packets are forwarded to the closest ITR, which is the border router of the destination edge network. This would work fine. That border router could encapsulate the packet and forward it to the ETR inside the edge network. There are a few variations on this . . . Firstly, maybe the border router is an ITR and the ETR is a separate router inside the network - but the border router has a route for the destination host's IP address already programmed into it, as part of the whole destination edge network being set up to send packets from the ETR to the destination host. Then, there would be no actual involvement of Ivip, other than this border router was advertising the whole "master-subnet" of which this destination IP address was a part. The fact that this border router received the packet means that it forwards it towards the destination host in its network. The ETR wouldn't be involved and there would be no encapsulation. This would be the case if the border router's FIB applied the local routing rules before the ITR function's rules - which it should. Secondly, if the border router's FIB applied the ITR functions first, then it would tunnel the packet to the ETR and all would be well. (Unless the ETR was itself, in which case it should just forward the packet on the internal routing system.) In either case, there would be no increase in path length - above any detour inside the destination network to reach the ETR. If the sending host and receiving host are in the same edge network, and if the whole edge network has its routers programmed to handle the IP address of the receiving host, then Ivip is not involved at all. If the sending host was in some other part of the edge network where the routers didn't know about how to route to the receiving host, then the packet would be forwarded towards the border router. En-route, if it encountered an ITR, all would be well. If the edge network had no ITR, then the packet would be forwarded out the border router and would find its way to the nearest ITR. Then it would be tunnelled back to the same edge network's ETR. This would definitely add to the path length! Here is a potential gotcha. Lets say a host has two links to ETRs in two edge networks A and B, and it is currently using the link to A. This means the global Ivip system's ITRs are tunnelling packets to A's ETR. Both edge networks must have their routing systems set up to forward packets for the recipient host's Ivip-mapped address (or subnet) to the link which leads to the receiving host. (For instance a router or a host computer with two fibre links to two ISPs.) Let's say there is a sending host in edge-network B. That sending host's packets will flow directly along the link from B to the recipient host, even though the recipient host is currently using the link to ISP for its connection to the Net. For absolutely full connectivity, either: 1 - The receiving host needs to accept packets from both links at once. or 2 - The network B needs to not forward the packets to the link to the recipient host until it somehow knows that the recipient host has switched to using network B's ETR. Option 1 sounds best. I apologise for the length of my messages. I hope that if you read them fully, you will understand Ivip and my idea of what LISP can be used for in a way which is independent of NEMO, mobile-IPv4/6 etc. I think the differences are more important than any similarities. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Jun 17 22:23: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 1I06tc-0003BL-Qh; Sun, 17 Jun 2007 22:23:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I06tb-00037B-Ae for ram@iab.org; Sun, 17 Jun 2007 22:23:11 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I06tZ-0007wK-Ti for ram@iab.org; Sun, 17 Jun 2007 22:23:11 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Jun 2007 04:23:10 +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 l5I2N9XM009226; Mon, 18 Jun 2007 04:23:09 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5I2MeDh028956; Mon, 18 Jun 2007 02:23:04 GMT Received: from xbh-hkg-411.apac.cisco.com ([64.104.123.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 04:22:55 +0200 Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:22:46 +0800 Received: from emakko.cisco.com ([64.104.9.16]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:22:45 +0800 Received: from mstenber by emakko.cisco.com with local (Exim 4.63) (envelope-from ) id 1I06t9-00048z-Us; Mon, 18 Jun 2007 11:22:44 +0900 From: Markus Stenberg To: Dino Farinacci Subject: Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels Organization: cisco Systems, Inc. References: <46720DED.9090608@firstpr.com.au> <1FDC4EF3-97D4-4CA7-A7EF-5012D4EA5DB8@cisco.com> <46723A5A.9000809@firstpr.com.au> <776CCBA4-FB53-4EC7-9733-C8E1F5CCC67C@cisco.com> <46724429.1040909@firstpr.com.au> <9D449908-6773-4AFB-A2E7-C3C669229F53@cisco.com> Date: Mon, 18 Jun 2007 11:22:43 +0900 In-Reply-To: <9D449908-6773-4AFB-A2E7-C3C669229F53@cisco.com> (Dino Farinacci's message of "Fri, 15 Jun 2007 00:54:56 -0700") Message-ID: <87lkeiypak.fsf@emakko.cisco.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 18 Jun 2007 02:22:45.0820 (UTC) FILETIME=[8EB667C0:01C7B14F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=975; t=1182133389; x=1182997389; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mstenber@cisco.com; z=From:=20Markus=20Stenberg=20 |Subject:=20Re=3A=20[RAM]=20ViP=3A=20Anycast=20ITRs=20in=20the=20DFZ=20&= 20mobile=20tunnels |Sender:=20; bh=H5CIVM2JDfjeZI40OykPUXS2NjTGWxdULDEPkdlMc5U=; b=Q0OdYaO9nnqelgqxW7sLI6xEbnwDy6/cPPf4Q8NLwv0y55+NPp0H8zQuz5ZjeRuo8TNLm/uE PhP6H+co/gxcWmehM232/ULMc9Z3thLJIiM5mgK/dqfFAiNiL9APSjNP; Authentication-Results: ams-dkim-2; header.From=mstenber@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Robin Whittle , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dino Farinacci writes: >> Christian, I think you understand what I am trying to say. It is >> not very complex and I don't expect it is very novel. But since I >> couldn't think of anything which does exactly this, I wrote it up. > But you require your address to be routeable all the time. If a site > requests Provider Independent (PI) addresses, your proposal requires > them to be routed in the core. > > That will not reduce the size of the routing tables. It does to a degree; if significant chunk of the PI space suddenly pointed to anycast-ITR of 'the other routing system' (whether you want to call it LISP or VIP, is academic), it could be aggregated and _not_ have any churn in it within the normal routing system. Of course, the question of whether or not the shifting of the routing load elsewhere really accomplishes anything is still there, but I thought that was the assumption with the LISP too? Cheers, -Markus _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 18 00:49: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 1I09BM-000208-HF; Mon, 18 Jun 2007 00:49:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I09BL-000200-Ur for ram@iab.org; Mon, 18 Jun 2007 00:49:39 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I09BL-0003Jw-Cj for ram@iab.org; Mon, 18 Jun 2007 00:49:39 -0400 Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 18 Jun 2007 23:18:08 +0530 X-IronPort-AV: i="4.16,432,1175452200"; d="scan'208"; a="82324386:sNHT61520990" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5I4nRNj008295; Mon, 18 Jun 2007 12:49:27 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5I4n5qE002831; Mon, 18 Jun 2007 04:49:19 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 12:48:36 +0800 Received: from emakko.cisco.com ([64.104.9.16]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 12:48:35 +0800 Received: from mstenber by emakko.cisco.com with local (Exim 4.63) (envelope-from ) id 1I09AJ-0004mZ-1I; Mon, 18 Jun 2007 13:48:35 +0900 From: Markus Stenberg To: Robin Whittle Subject: Re: [RAM] Ivip (was ViP ...) Organization: cisco Systems, Inc. References: <4673CF77.5040800@firstpr.com.au> Date: Mon, 18 Jun 2007 13:48:34 +0900 In-Reply-To: <4673CF77.5040800@firstpr.com.au> (Robin Whittle's message of "Sat, 16 Jun 2007 21:54:31 +1000") Message-ID: <87hcp5zx3x.fsf@emakko.cisco.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 18 Jun 2007 04:48:36.0099 (UTC) FILETIME=[EE490530:01C7B163] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2789; t=1182142167; x=1183006167; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mstenber@cisco.com; z=From:=20Markus=20Stenberg=20 |Subject:=20Re=3A=20[RAM]=20Ivip=20(was=20ViP=20...) |Sender:=20; bh=uqNObQIfHK20ybEHhF8UFnQw2zyf/5yT2CI8Mmur64k=; b=l7pKIhuKHdD8g3qmUnNKHM46C7ng7t0bUROSMKsZ5oLvLzJGo+h8iBDgwJOAdg4Ub/D+9x/5 1d10eXhOoajsijy9zYNLSaPH+0FKS4CYigJEC4zsszvWdRDNYBZE+A7Ip7Mpinyw2MDO5oqVrC 9c5oGTizQUHX/Spg90Mt8d5LU=; Authentication-Results: hkg-dkim-1; header.From=mstenber@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Christian Vogt , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Robin Whittle writes: > Whether a LISP or Ivip ITR uses push (has the complete database at > all times) or pull (has to query, learning not to query about > prefixes for which it recently got a "not mapped" response), the FIB > function has a lot of work to do and a large amount of data to > store. My current feeling is that this can and should be done by a > smaller number of really advanced routers, such as the CRS-1, with > lots of memory and flexible dedicated CPUs (188 32 bit CPUs on a > single ASIC, the world's largest) - rather than on a larger number > of smaller ones. I think that as an employee of a hardware company, selling big hardware is a good; however, in practise, I think that it would be more reasonable to provide support for both pull and push, especially if you plan to add churn to the system. The churn numbers caused by more mobile (and/or TE-using?) users on centralized routers (and the communication channel between them used for 'push' traffic) would be insane, and non-core router could not handle that sort of non-scoped 'push' traffic anyway. The pure-push model with per-host information granularity sounds likely to make the scalability problem bigger, not smaller.. The typical arguments against pull solution are as follows: - there is connection delay - routers cannot store packets due to NGbps interface(s) it is saturating - => there is packet loss if the router in middle needs to do lookup However, the connection delay is there already in significant number of cases (DNS), and it isn't making the world a much worse place. About the packet storage, or percentage of meaningful packets that need to be stored during pull lookup - in typical case, - frequently more than one connection per destination, (HTTP, FTP, some P2P protocols), - more than one source per destination, (some destinations being more equal than others), and - traffic would most likely stop around first packet until lookup was completed anyway due to very few protocols blasting (meaningful) traffic without replies from the other end. (in case of HTTP, the client wouldn't even open more connections before the first request completes.) I know for a fact that the ~1 packet caching pull has been used in on-demand L2TP and VPN solutions. I'm curious about how the numbers would work in core or large customer networks though. Anyone have any concrete data? For anything smaller scale, it is clearly doable given modern hardware. Cheers, -Markus (*) I tried to look up some on the intarweb, but unfortunately all netflow repositories I could find seemed to be of 'if you are researcher, snailmail us with application in triplicate for processing' nature.. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 18 02:25: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 1I0Ag3-0000ZH-ET; Mon, 18 Jun 2007 02:25:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Ag2-0000Mr-47 for ram@iab.org; Mon, 18 Jun 2007 02:25:26 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Ag0-0004iR-2K for ram@iab.org; Mon, 18 Jun 2007 02:25:26 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 5340A59DE9; Mon, 18 Jun 2007 16:25:21 +1000 (EST) Message-ID: <46762547.30107@firstpr.com.au> Date: Mon, 18 Jun 2007 16:25:11 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Ivip (was ViP ...) References: <4673CF77.5040800@firstpr.com.au> <87hcp5zx3x.fsf@emakko.cisco.com> In-Reply-To: <87hcp5zx3x.fsf@emakko.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Hi Markus, You wrote: > I think that it would be more reasonable to provide support > for both pull and push, especially if you plan to add churn > to the system. The churn numbers caused by more mobile > (and/or TE-using?) users on centralized routers (and the > communication channel between them used for 'push' traffic) > would be insane, and non-core router could not handle that > sort of non-scoped 'push' traffic anyway. The pure-push model > with per-host information granularity sounds likely to make > the scalability problem bigger, not smaller.. I agree there needs to be an option for smaller ITRs to operate with less state and to use a "pull" query-based approach. This would also enable a host to do its own ITR function. If this was implemented widely in operating systems, the system (LISP or Ivip) would be highly scalable, since each host doesn't have to store much state, unless perhaps it is a big server. However, the system would still work fine for hosts without built-in encapsulation. Peer-to-peer file-sharing networks may send packets to lots of hosts all over the Net. This could be quite a burden on LISP/Ivip compared to traditional two-way communication. On one hand I am attracted by the idea of fewer really fast ITRs, each with the whole mapping database in their FIB. But when I think about millions or hundreds of millions of separate mappings, for individual IP addresses and for small and large subnets, it becomes very daunting to receive these updates, and to change the FIB accordingly, not to mention having an FIB which could actually store them. I think the FIB always needs to know what ranges of addresses are being mapped via Ivip (the one or probably hundreds or thousands of "master-subnets", each of which may be split into different mappings). Otherwise, whenever a packet arrives which is not in one of these subnets and not matched by a BGP prefix, the ITR has to query the central database. The central database would need to tell all the ITRs what subnets of the whole address space are currently covered by the LISP/Ivip mapping system. I figure this would change only slowly. When a "pull" ITR receives a packet whose destination is an IP address within a "master-subnet" and the ITR doesn't have up-to-date mapping information for that address, it queries the central database (or a distributed database or whatever). The replies need to come with a caching time and a description of the subnet they refer to. For instance, if there is a subnet all mapped to the IP address of one ETR and the ITR queries the database about a specific IP address within this range, then the database needs to reply not just with the IP address of the ETR, but with: This address to reach the ETR should be used for the range of IP addresses X to Y. Cache this result for 300 seconds. If the database has no mapping for the IP address which the query concerns, it needs to tell the ITR something like: There is no mapping for this IP address or for the surrounding range of addresses X to Y. Cache this result for 3600 seconds. > I think that as an employee of a hardware company, selling big > hardware is a good; . . . I have some idea of the heroics of the CRS-1's 188-CPU ASIC and its banks of reduced latency DRAM, running the Tree-Bitmap algorithm: http://www.firstpr.com.au/ip/sram-ip-forwarding/router-fib/#Cisco_CRS_1 The FIB of a busy ITR is a daunting prospect - and it must be done with one or more CPUs and multiple fast RAM lookups using something like Tree-Bitmap, because TCAM can't do it. TCAM can't scale to the number of Ivip/LISP mappings. These will be in the millions to hundreds of millions over time, and it has some really nasty update gotchas when there is a need to move a lot of rules to different locations in the TCAM. I guess the CRS-1's SPP chip is highly flexible and would be as good a basis for doing the fancy ITR FIB as any other piece of hardware which currently exists. Before deciding that LISP, Ivip or whatever was the way forward, it would be best to have a reliable estimate of how many mappings and packets per second the CRS-1 MSC's Ingress FIB SPP system could be programmed to handle. I guess that new firmware would be required for the best results. At least the FIB, central CPU and communications heroics of a LISP or Ivip ITR only need to be implemented on a fraction of the routers in the Net. Without something like this, we would have to go to about this much trouble for all the DFZ routers before too long. As far as I know, the ETR function of decapsulating an IP-in-IP packet is pretty easy. Can routers with current firmware be configured to do this? Maybe the overall LISP/Ivip system would require some extra functionality in the ETR, perhaps to confirm that the destination host was reachable - if ping or some alternative techniques were blocked for security reasons. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 18 03:13: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 1I0BQO-0006HH-6o; Mon, 18 Jun 2007 03:13:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0BQM-0006HB-DY for ram@iab.org; Mon, 18 Jun 2007 03:13:18 -0400 Received: from ns2.nict.go.jp ([133.243.3.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0BQH-00074q-Kr for ram@iab.org; Mon, 18 Jun 2007 03:13:18 -0400 Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns2.nict.go.jp with ESMTP id l5I7D1ba011198; Mon, 18 Jun 2007 16:13:01 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id l5I7D1uw003666; Mon, 18 Jun 2007 16:13:01 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id l5I7D1tn003663; Mon, 18 Jun 2007 16:13:01 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id D317A6E9C; Mon, 18 Jun 2007 16:13:00 +0900 (JST) Received: from nictkafle (5gou2f-dhcp28.nict.go.jp [133.243.146.188]) by mail2.nict.go.jp (Postfix) with ESMTP id A460B6E92; Mon, 18 Jun 2007 16:13:00 +0900 (JST) From: "Ved Kafle" To: "'Robin Whittle'" , Subject: RE: [RAM] Ivip (was ViP ...) Date: Mon, 18 Jun 2007 16:14:45 +0900 Message-ID: <001201c7b178$5c2e0460$bc92f385@nictkafle> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <46751FC2.30804@firstpr.com.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e07cb4561b0bc070cf5c9de2a587f312 Cc: 'Christian Vogt' X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Robin: Thanks for your detail clarification. I just add a few points here. In my opion, the difference between the mobile IP and Ivip is based on the following points: (1) types of addresses used to identify end hosts; (home address vs. PI addresses) (2) where the mapping information is maintained in; (home agent vs. ITR, ETR, TTR) (3) where tunnels start and where they end (home agents and mobile host vs. ITR and ETR or TTR) Home agents are confined to home networks whereas ITRs can be distributed in the Internet. Home agents advertise the reachability to mobile host's home addresses whereas ITRs advertise reachability to Ivip-mapped addresses. Ivip assumes that many ITRs may advertise the same prefix. Mobile IP research is quite matured by now. From this experience, we can explore if Mobile IP can be extended to cover the Ivip type distributed mapping system by forming a federation of home agents and advertising many network prefixes by each member of the federation. Ivips distributed ETRs share some common features with the MAPs (mobility anchor points) of hierarchical mobile IP. (How about pushing MAPs further deep into the network, so that they function as TTR?) Let's think if Ivip can get benefits from Mobile IP experience, or Mobile IP can get benefits from the Ivip idea. Ved > -----Original Message----- > From: Robin Whittle [mailto:rw@firstpr.com.au] > Sent: Sunday, June 17, 2007 8:49 PM > To: ram@iab.org > Cc: Christian Vogt; Ved Kafle > Subject: Re: [RAM] Ivip (was ViP ...) > > > I am replying to Ved's and Christian's comments in "Re: ViP: > Anycast ITRs in the DFZ & mobile tunnels", with "ViP" changed > to "Ivip" (eye-vip). > > I apologise for the length again. It would probably not be > so hard to describe Ivip to one person, face-to-face, with > conversation and hand-drawn diagrams. Trying to do it for a > bunch of people via email takes more words. > > > VK> To me, the Ivip approach looks similar to the network mobility > VK> (nemo) support approach being discussed in the IETF nemo WG. In > VK> nemo, the mobile router's home agent advertises the > mobile network > VK> prefix such that the packets sent by a correspondent node to an > VK> address belonging to the nemo prefix go to the home > network of the > VK> mobile network, where the home agent tunnels them to the current > VK> location of the mobile router. The mobile router decapsulates and > VK> forwards the packets to the addressed node. > > I threw this proposal together quickly without checking other > protocols - and I don't claim it is highly original. > > There are two aspects to the proposal at present: > "Ivip-basic" and "Ivip-mobile". > > Ivip-basic > ---------- > > H1---(ITR1)---\ > / \ > H2-/ \ > (ETR1)----RH > / > H3---(ITR2)----/ > > (ITR3) (ETR2) > > > Sending hosts H1, H2 and H3 are assumed to have ordinary IP > addresses, reachable via BGP. The ITR function is generally > performed in border routers or transit routers, but can be > performed in interior routers of the edge network. > > Packets from the Receiving Host RH flow by ordinary BGP > routers back to the sending hosts. If a sending host is also > using an Ivip-mapped IP address, then the same process occurs > in reverse, with the packet sent by RH finding their way to > the first ITR, probably at or near the border router of its > edge network, and being encapsulated and sent to the ETR for > the host on the left side. None of this is shown in the > above diagram. > > ETRs are provided by ISPs, or the AS-end-users who run the > edge networks. They only serve receiving hosts in those > edge networks. > > How does the edge network know that the decapsulated > packets emerging from the ETR must be sent to a particular > host in its network? The ETR and the routers nearby > need to be configured to look out for this IP address, > or the Ivip-mapped subnet, and route it internally to the > receiving host. With Ivip, these packets are addressed to a > prefix (a large subnet I call the "master-subnet") which is > advertised in BGP. With LISP, they are not. > > To support either LISP-mapped or Ivip-mapped IP addresses, > the edge network needs not only an ETR to decapsulate the > packets, but it needs a routing rule specific for that IP > address or subnet which directs packets addressed to that > address or subnet to wherever the particular host is located. > > This is probably a non-trivial task for an edge network, > but the are being paid by their customer with the host which > uses LISP-mapped or Ivip-mapped addresses. > > > Assuming a single global Ivip system, the ITRs may be > provided by various operators, but work as a single system, > without any constraints on whose packets they will encapsulate. > > What may be unique about Ivip is that these ITRs are numerous > and located (usually) at border or transit routers where any > sender's packets will eventually be sent to one. What may > also be unique is the idea that all these ITRs advertise the > same set of prefixes: whatever "master prefixes" the Ivip > system handles. > > Generally, these "master prefixes" are split into many > smaller sections, each with a different mapping to an ETR. > This works fine down to individual IP addresses. There needs > to be a single central system for controlling the mapping - > and every ITR has an up-to-date copy of this database. > > Ivip-basic is a one-way, public, system. Ideally it would be > provided for free, but there probably needs to be some fees > for running the ITRs and administering the database. These > could be paid for by the Ivip "customers" - those individuals > and organisations etc. who pay for one or more IP addresses > in the system. > > As shown above, the ETRs are in the edge network in which > RHs are located or connected to. > > Each RH in this depiction has a single link to its ETR, but > an RH could easily have links to two ETRs, especially in two > edge networks, to achieve multihoming. > > > Ivip-mobile > ----------- > > Ivip-mobile is an extension of the above, but would probably > always be a commercial service. There could be any number of > Ivip-mobile operators. Each would have a set of special ETRs > called TTRs (Translating Tunnel Routers). These TTRs are in > general either at border routers or more likely amongst the > transit routers. TTRs could also be in edge networks. > > H1---(ITR1)---\ > / \ > H2-/ \ > (TTR1)~~~~~~~~MH > / / > H3---(ITR2)----/ / > / > (ITR3) (TTR2)~~~~/ > > > The Mobile Host (MH) could be behind NAT and always > establishes an encrypted 2-way tunnel to at least one TTR. > (I am assuming an encrypted and compressed 2-way VPN-like > tunnel, but I guess it could also be done by simple two-way > IP-in-IP tunnelling.) > > The Mobile Host may establish tunnels to multiple TTRs, > including using completely different links, such as ADSL and > GPRS radio. > > The Ivip system maps the MH's IP address (or prefix) to one > of the TTRs, so all the encapsulated packets from the world's > ITRs arrive at that TTR. Some central monitoring system > could detect that one TTR is dead, or that its link to the MH > is dead, and then the mapping could be changed to the other > active TTR. > > To the Ivip system, which is really the ITRs and their > controlling database, there is probably no way of telling > whether the currently mapped-to IP address points to an ETR > which is for Ivip-basic (meaning the RH is in an edge network > and the ETR is a border or internal router of that edge > network, with packets flowing back independently of these > arrangements) or whether the mapped-to IP address points to > a TTR. > > A TTR is simply an ETR which the MH tunnels to, and which > therefore also acts like the MH because this TTR is where the > MH's outgoing packets are first let loose on the Net. > > With mobile-IPv6 (as I understand it), there is exactly one > router which the MH tunnels to - it is the router which runs > the LAN in which the MH's home address is located. > > Mobile-IPv6 can also cause corresponding hosts (H1 to H3 > etc.) to send packets to and from the MH directly, rather > than using the home router. This is more efficient, but > requires the corresponding host to have special mobile-IPv6 > capabilities. > > Ivip-mobile is very different from mobile-IPv6 in that the MH > can choose one or more TTRs to tunnel to. Ideally it will > choose the ones which are closest to its current location. > Also, there is no "home IP address" on a LAN, as there must > be with mobile-IPv6. > > As far as I know, mobile-IPv4: > > http://www.mip4.org > > relies on a "home-router" and home IP address too. > > Likewise, as far as I know, NEMO does as well: > > http://tools.ietf.org/html/rfc3963 > http://tools.ietf.org/wg/nemo/ > > Also, like LISP, Ivip works with single IP addresses or any > number of IP addresses. I am not sure whether mobile-IPv6, > mobile-IPv4 support subnets, but I guess they could do it as > individual arrangements for multiple IP addresses. NEMO > supports subnets. > > > The reason a figment of our imagination like Ivip can boldly > invoke a worldwide network of ITRs while mobile-IPv6/4 cannot > is that now we are desperate. > > If we don't do something on a grand scale such as this, we > will all be doomed to paying for endless upgrades to all the > Internet's transit and multihomed border routers as the BGP > routing table grows to 500,000, 1,000,000, 2,000,000 etc. > > LISP boldly invokes at least one ITR in every edge network > which has a host which needs to communicate with a host or > network whose IP address or subnet is handled by LISP. In > practice, for LISP-mapped IP addresses to be attractive to > anyone, this means most edge networks must have one or more ITRs. > > Ivip less boldly invokes ITR functions broadly distributed in > the border routers and transit routers. I can get away with > this, as can the LISP authors, because we are desperate. > > Both LISP and Ivip require the relatively modest ETRs to be > installed in the edge network of any host which has its > address or subnet handled by LISP or Ivip. > > Ivip could also exist as multiple independent networks of > ITRs, each with its own "master-subnets" and its own central database. > > Since Ivip involves a bunch of souped-up routers at border > router and transit router locations, it is not much more of a > step to have some of these, or perhaps separate networks of > routers, performing TTR functions. Each TTR system could be > entirely independent of other TTR systems, and of the one or > more ITR systems (provided the TTR did not also implement ITR > functions). The multiple TTR systems could compete and > provide commercial services to the customers who they provide > Ivip-mapped address space for. > > Please see my previous long message where I write about > my conception of Ivip or LISP, which I think is different of > Dino's "BYO address space" vision for LISP. > > If there was a single Ivip system of ITRs, presumably the > system would not be allowed to fail, so any address space it > hands out via its mapping functions would be essentially > "Provider Independent". > > If there were competing Ivip systems, then all of them, > apart from perhaps one "universal public" one, would be > dependent on some company, ISP etc. and be for-profit - so > the IP address still depends on that company. > > However, in both cases, where the customer whose address is > mapped by these systems chooses to attach to the Net (their > choice of ISPs) is completely unrelated to the Ivip system(s). > > Any TTR systems could be independent of the Ivip systems. > > A customer could choose to use any number of competing TTR > systems. They have nothing to do with IP addresses, since > their TTRs are only of value to the customer if the ITRs > tunnel packets to the TTRs, and since the customer pays for, > or has control of, the mapping of their IP address, the > customer only depends on the ITR system for the security of > "tenure" of this address - and not at all on any TTR systems it uses. > > > Each TTR could also act as an ITR for that system's > "master-subnets". If there was a single, global, system of > ITRs, it would be good if the privately run TTRs also acted > as ITRs within the global Ivip system. > > Otherwise, packets would have to first find an ITR and be > tunnelled to the TTR when they are going to an Ivip-mobile host. > > For simplicity, the following assumes there is a single > set of "master-subnets" (AKA "master-prefixes") which are > handled by a single Ivip system which includes an Ivip-mobile > function as well. > > It is likely that a router which performs TTR functions will > also act as an ITR. > > H1------(TR)------------(ETR1)------RH1 > \ > MH2~~~~~~(TTR1)~~~~~~~~MH1 > / \ > H2----(ITR1) \ > / (TR) > H3----/ \ > \ > MH3~~~~~~~~~~~(TTR2) > > H1 and H2 have ordinary BGP routed IP addresses. Packets > sent from H1 to MH1 are received by TTR1 which acts like an > ITR. Ordinarily, an ITR encapsulates the packet and tunnels > it to the ETR to which the destination (MH1) IP address is > mapped to. In this case, TTR1 is the destination ETR, so > there is no need to encapsulate the packet. It is simply > placed on the VPN 2-way tunnel ~~~~~~~~ and sent to MH1. > > Packets from MH1 to H1 follow the reverse path - they come > out of the VPN tunnel at TTR1 and are forwarded via normal > BGP routing back to H1. > > The same would be true between H1 and MH2. > > Packets from H2 to MH1 (or MH2) would be encapsulated by ITR1 > and tunnelled (one way, IP-in-IP) to MH1's ETR, which is > TTR1. TTR1 decapsulates them and sends them on the VPN tunnel to MH1. > > Packets from MH1 to H2 pop out of the VPN tunnel at TTR1 and > use ordinary BGP forwarding to get to H2. > > RH1 has an Ivip-mapped IP address. It is not using > Ivip-mobile - just Ivip-basic. > > In this diagram, the nearest ITR to H1 is TTR1. When H1 > sends a packet to RH1, it is forwarded by the TR transit > router to TTR1, and encapsulated. TTR1 sends the packet in a > 1-way IP-in-IP tunnel to ETR1 (at the border of, or within an > edge network), which forwards it within the edge network to RH1. > > Packets from RH1 must be accepted by the border router of its > edge network (which could be ETR1 or some other router not > shown) and are sent via ordinary BGP forwarding to H1. > > A packet from MH3 to MH1 goes via 2-way VPN tunnel to TTR2 > where it is encapsulated and sent on a 1-way IP-in-IP tunnel > to MH1's ETR, which is TTR1. This decapsulates it and sends > the packet along its 2-way VPN tunnel to MH1. Packets going > from MH1 to MH2 follow exactly the opposite path, with a > 1-way encapsulated IP-in-IP tunnel from TTR1 to TTR2. > > Mobile-IPv6 doesn't assume anything about routers, except its > home router. It doesn't assume anything about corresponding > hosts, since ordinary hosts can simply communicate with the > mobile host as if it was at its home location, with the home > router tunnelling to and from the mobile host, wherever it is. > > Ivip doesn't assume anything about corresponding hosts, or > the host whose IP address or subnet is mapped by Ivip. > > Ivip does assume there is a system of ITRs - ideally all > around the Net at border routers and transit routers. > > Ivip requires the receiving host have at least one ETR. For > Ivip-basic, there will be one ETR in the edge network where > the receiving host is currently connected. This mapping can > be switched to another ETR, for instance for multihoming. > There could also be load balancing between multiple ETRs, as > LISP proposes. > > > VK> Analogy: > VK> (1) Ivip routers are similar to the mobile network home agents, > VK> except that the home agents are confined to home networks > VK> where as Ivip routers may be distributed in the Internet. > > Yes, but the TTRs are similar to the home-agent. With > Ivip-mobile the mobile host's IP address doesn't have a home > anywhere. Packets from ordinary IP addresses are tunnelled > by ITRs to the currently chosen ETR, and that ETR (in the > case of a mobile host) is a TTR which the mobile host has a tunnel to. > > This means that wherever the mobile host is and wherever the > corresponding hosts are, assuming there are plenty of ITRs > and TTRs, the total path length will be the same as, or not > much longer, than without Ivip. > > VK> If we suppose that home agents can be distributed like Ivip > VK> routers, then these two approaches are exactly the same. > > In my perhaps faulty understanding of mobile-IPv4, > mobile-IPv6 and NEMO, this could not occur, because the > home-agent router needs to be connected to an edge network > whose border router advertises the address range the router > handles. It can't be moved somewhere else, assuming that > router only handles a part of the subnet its edge network > advertises, because to do so would create two or three BGP > advertisements instead of one. > > > VK> (2) Ivip's ETRs are similar to nemo mobile routers, which update > VK> Ivip routers (home agent) with the tunnel-end addresses. > > I read the first ten pages of NEMO's RFC3963. NEMO extends > mobile-IPv6 with a "mobile router". This is somewhat like a > mobile-IPv6 mobile node, except it is a router which has > links to the multiple mobile hosts. Also, there is no "route > optimization" as in mobile-IPv6 where capable correspondent > nodes can send packets directly to and from whatever IP > address the mobile host (or NEMO mobile router) is currently > located at. So with NEMO, all traffic to the multiple mobile > nodes goes through the fixed location (I assume) home agent > router, and then via a two-way tunnel to the mobile router > - which can flit from one IP address to another, taking its > flock of mobile nodes with it. > > I don't think there is much resemblance between any of these > pre-existing mobile systems and either Ivip-basic or its > Ivip-mobile extension. > > Ivip's notion of large numbers of public ITRs and TTRs (by > paid-for access I guess) with the mobile host choosing which > TTR to use at any time, does not seem to have a parallel in > these pre-existing mobile systems, which assume a fixed > home-agent router. > > Ivip-mobile will only be possible because there will be > a global system of ITRs which tunnel packets to any > BGP-reachable IP address is currently selected to act as the > ETR for the mobile-host's Ivip-mapped IP address. > > Without that global ITR system, steering packets anywhere on > the NET, the pre-existing technologies mobile-IPv4/6-NEMO > must rely on all packets going to a home-agent router, except > for mobile-IPv6 which can use "route-optimization" and set up > smart-enough correspondent nodes to send packets directly to > and from the mobile node. > > LISP could just as easily be extended as I suggest with > Ivip-mobile. Ivip is similar to or identical to LISP, or at > least some type of LISP, except that it should be easy to > incrementally deploy and except that it does require all its > "master-subnets" (hopefully few and large) to be advertised in BGP. > > > VK> (3) In nemo, a bidirectional tunnel is set up to avoid packet > VK> filtering at border routers. Whereas in Ivip, it is assumed > VK> that the BRs forward packets with Ivip-mapped addresses. > > In Ivip-basic, with the receiving host semi-permanently in an > edge network, I assume that the edge network's routers are > programmed to allow packets from its IP address to be sent to > the global BGP system. If not, then the receiving host would > need to use Ivip-mobile with a TTR outside this edge network. > > I tend to think of the TTR function being implemented within > routers which are already transit routers, or in routers > which are located at peering points and are primarily > connected to transit and border routers. However a TTR could > be a border router or inside an edge network, as long as that > border router or edge network allowed egress of the outgoing > packets (which could have almost any source address) to the > BGP routing system. > > > VK> There are some well known problems associated with such anchor > VK> point-based approaches, such as increased packet delivery delay, > VK> non-optimal routing, tunnelling overhead, possibilities of single > VK> point of failure, etc. To avoid these problems, route > optimization > VK> mechanisms are being investigated in the nemo WG. > Shouldn't we look > VK> for the ID-loc split solutions that avoid such problems > as much as > VK> possible? > > Ivip-basic isn't at all like these pre-existing mobile > protocols. The Ivip-mobile extension only loosely resembles > them, because there is no one fixed home agent. > > Altogether, Ivip-basic and Ivip-mobile should enable packets > to flow without much extra distance or hops. There is still > a tunnelling overhead, and perhaps problems with MTU limits. > > > Christian Vogt quoted Ved Kafle and responded: > > VK> To me, the Ivip approach looks similar to the network mobility > VK> (nemo) support approach being discussed in the IETF nemo WG. ... > CV> > CV> Absolutely. This is what I was saying. > > I think Ivip is very different from NEMO etc. > > > VK> Analogy: > VK> (1) Ivip routers are similar to the mobile network home agents, > VK> except that the home agents are confined to home networks > VK> where as Ivip routers may be distributed in the Internet. > CV> > CV> Actually, Ivip routers are confined in the same way as > home agents > CV> in that both can only support "home" prefixes that correspond to > CV> their topological location in the Internet. > > As I explained above, and in a long message which started > this thread, this is not the case. There are lots of TTRs to > choose from, so ideally the mobile node will choose one close > to it. This is only possible because there is a global > network of ITRs, acting like a coordinated bunch of mirrors, > tunnelling all the mobile node's traffic to this TTR, another > TTR or wherever the mobile node (or some other control > system) tells the ITRs to tunnel the packets to. > > > CV> After all, the idea of Ivip routers is to have them advertise > CV> sub-prefixes from their ISP's global routing prefix so that the > CV> sub-prefixes can be aggregated with the global routing > prefix and do > CV> not require a separate slot in the DFZ routing table. > > An Ivip ITR is one of many which advertises one or more > "master prefixes". Each ITR attracts packets addressed to > these prefixes and tunnels them off to potentially millions > of different ETRs. A TTR acts like an ETR as far as the ITR > system is concerned. Its just that a TTR is probably not in > an edge network - and it connects to the host which has the > Ivip-mapped IP address via a two-way tunnel. > > > VK> There are some well known problems associated with such anchor > VK> point-based approaches, such as increased packet delivery delay, > VK> non-optimal routing, tunnelling overhead, possibilities of single > VK> point of failure, etc. ... > CV> > CV> Right. And things don't get better if we do the > indirection for all > CV> hosts, not just mobile hosts or hosts moving with mobile networks. > > Other than the central database, I don't think there is a > central point of failure for Ivip-basic or its Ivip-mobile > extension. Assuming the mobile host has a BGP reachable IP > address, or is behind a NAT firewall which has such an > address, it can set up a two-way tunnel to one or more TTRs. > If one goes down, it can use another. Ideally it would use > nearby ones. > > Ivip-basic, like LISP, relies on the receiving host having a > connection to a particular ETR. LISP, Ivip-basic and > Ivip-mobile all enable the receiving host to set up links to > multiple ETRs and then (directly, or by some automatic > system, since the receiving node could be out of contact > after the failure of its active link) the ITRs can all be > told to tunnel packets to whichever ETR is currently used. > > This is genuine multihoming, including for Ivip-mobile - if > the two links to the two TTRs are by physically different networks. > > > VK> To avoid these problems, route > VK> optimization mechanisms are being investigated in the nemo WG. > VK> Shouldn't we look for the ID-loc split solutions that avoid such > VK> problems as much as possible? > > > CV> Without an intention to prefer either mechanism, I just > want to note > CV> that the advantage of Ivip is a better transition path, > whereas LISP > CV> performs better from the perspective of packet > propagation latencies > CV> and fault tolerance. > > Thanks for agreeing with what I think is the most important > difference - that Ivip looks like it would be easier to introduce. > > > CV> As a matter of fact, LISP is nothing else but route > optimization (in > CV> Mobile IPv6 terms) for Ivip. > > LISP has the ITR function inside or at the border of the > edge network. Ivip typically has the ITR function at the > border router or amongst the transit routers. > > With LISP, if the ITR function is at the border router > or in an internal router which is on the shortest path > between the sending host and the border router, then the > total path likely to be the same as for a direct packet > (other than a potentially longer path in the destination > edge network if the ETR isn't exactly on the shortest > path to the receiving host). > > With Ivip, the same is true if either of the following > typical conditions is true: > > 1 - The ITR function is at the border router of the > sending edge network. > > 2 - The ITR function is in a transit router which is on > the shortest path towards the destination edge > network's border router. > > So Ivip's total path length would only be longer than LISP's > if the ITR function was not in the sending edge network's > border router but in a transit router (or perhaps another > border router of another edge network) which is off the > shortest path to the destination network's border router. > > If Ivip or some similar system is adopted, before long, any > ISP or AS-end-user network with any substance would want to > install the ITR function at its border routers and/or at > internal routers - to reduce the processing load on the > border routers. They would want to do this so their outgoing > Ivip-mapped packets do not depend on anyone else's external ITRs. > > A fully hardware optimised ITR, with its big database and > need for constant updates from the central Ivip database, > could be quite expensive. But it has to be provided either > by the edge network, or by some ISP or transit provider > the edge-network uses for its upstream links. > > I am not sure how the economics would work best. Maybe > for smaller ISPs and AS-end-user edge networks it would > be better to pay their upstream provider to handle the > ITR function. > > Over time, as ITR-capable hardware costs reduced, more and > more smaller ISPs and AS-end-user networks would probably > find it better to run their own ITR rather than pay to use > their upstream provider's ITR. > > I think only those smaller edge-networks would not run > ITRs in the long-run. The most important thing is that Ivip > could start running with just a handful of ITRs somewhere in > the Net. Ideally there would be multiple ITRs for each country. > > The only significant path-length increases with Ivip would > occur when the sending edge network is nowhere near an ITR. > > This would occur in the early days of introduction. > > But once Ivip became established and a significant amount > of traffic was reliant on ITRs, competition between > upstream providers would cause them to ensure there were > ITRs in upstream paths, rather than off to one side somewhere. > > There are two other situations of practical interest, in > which Ivip would also produce no increase in total path > length. > > Firstly, it is perfectly possible to install Ivip ITRs inside > edge networks. Then, the situation would be identical to > LISP: assuming the ITR was on the path from the sending host > to the border router, there would be no extra path length. > > Edge networks could install internal ITRs to take the load > off their border routers. However, this would slightly add > to the traffic load inside the network, due to the IP-in-IP overhead. > > The second scenario is most likely to occur when the > destination edge networks are very close or their routers are peers. > > If the sending edge network has no ITR, the packets are > forwarded to the closest ITR, which is the border router of > the destination edge network. This would work fine. That > border router could encapsulate the packet and forward it to > the ETR inside the edge network. There are a few variations > on this . . . > > Firstly, maybe the border router is an ITR and the ETR is > a separate router inside the network - but the border router > has a route for the destination host's IP address already > programmed into it, as part of the whole destination edge > network being set up to send packets from the ETR to the > destination host. Then, there would be no actual involvement > of Ivip, other than this border router was advertising the > whole "master-subnet" of which this destination IP address > was a part. The fact that this border router received the > packet means that it forwards it towards the destination host > in its network. The ETR wouldn't be involved and there would > be no encapsulation. > > This would be the case if the border router's FIB applied the > local routing rules before the ITR function's rules - which it should. > > Secondly, if the border router's FIB applied the ITR > functions first, then it would tunnel the packet to the ETR > and all would be well. (Unless the ETR was itself, in which > case it should just forward the packet on the internal > routing system.) > > In either case, there would be no increase in path length - > above any detour inside the destination network to reach the ETR. > > If the sending host and receiving host are in the same edge > network, and if the whole edge network has its routers > programmed to handle the IP address of the receiving host, > then Ivip is not involved at all. > > If the sending host was in some other part of the edge > network where the routers didn't know about how to route to > the receiving host, then the packet would be forwarded > towards the border router. En-route, if it encountered an > ITR, all would be well. If the edge network had no ITR, then > the packet would be forwarded out the border router and would > find its way to the nearest ITR. Then it would be tunnelled > back to the same edge network's ETR. This would definitely > add to the path length! > > > Here is a potential gotcha. > > Lets say a host has two links to ETRs in two edge networks > A and B, and it is currently using the link to A. This means > the global Ivip system's ITRs are tunnelling packets to A's ETR. > > Both edge networks must have their routing systems set up > to forward packets for the recipient host's Ivip-mapped > address (or subnet) to the link which leads to the receiving > host. (For instance a router or a host computer with two > fibre links to two ISPs.) > > Let's say there is a sending host in edge-network B. That > sending host's packets will flow directly along the link from > B to the recipient host, even though the recipient host is > currently using the link to ISP for its connection to the Net. > > For absolutely full connectivity, either: > > 1 - The receiving host needs to accept packets from both > links at once. > > or > > 2 - The network B needs to not forward the packets to the > link to the recipient host until it somehow knows that > the recipient host has switched to using network B's > ETR. > > Option 1 sounds best. > > > I apologise for the length of my messages. I hope that > if you read them fully, you will understand Ivip and my > idea of what LISP can be used for in a way which is > independent of NEMO, mobile-IPv4/6 etc. I think the > differences are more important than any similarities. > > - Robin > > > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 18 04:00: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 1I0C9x-0007wN-2q; Mon, 18 Jun 2007 04:00:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0C9v-0007tQ-Ro for ram@iab.org; Mon, 18 Jun 2007 04:00:23 -0400 Received: from mu-out-0910.google.com ([209.85.134.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0C9u-0001hg-Im for ram@iab.org; Mon, 18 Jun 2007 04:00:23 -0400 Received: by mu-out-0910.google.com with SMTP id g7so1736536muf for ; Mon, 18 Jun 2007 01:00:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Tzu6Vbn33NJXKkjjssZ96RMhIihUxgqETBNIcBZamGXgGfODolJnWqufuhHiXiWhV2Q3GmB20ELhoei1wRbT9+zgjD12FUUB/Y8prbOZcLd/unIFjiURT3MvBaa7tIx/jC3XY/V5uaEsPFAS+GfcHirqogN7G8ujr0gIfVbQFgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=VJslCofmnJT2GoGI/6xgRICoH6c1HBXDNn3Tsv9DFWgbPXHJGJzdpyXhQsbGzHEc38rAx9uBhxeP8Kpymwpu3amEcSVMdaZXN/DuAL/JHJ1fb7PGd2JK/KxdUjYdIO5YqpYPL94evGXFkc2pdRgLmicpTMBLuPT2yPvm5qAGwX0= Received: by 10.82.175.17 with SMTP id x17mr10680676bue.1182153621528; Mon, 18 Jun 2007 01:00:21 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id 6sm4589132nfv.2007.06.18.01.00.19 (version=SSLv3 cipher=RC4-MD5); Mon, 18 Jun 2007 01:00:20 -0700 (PDT) Message-ID: <46763B92.9050200@gmail.com> Date: Mon, 18 Jun 2007 10:00:18 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] DNS usage in NERD References: <1733F2C0-324A-4C66-9904-F0B597271642@extremenetworks.com> In-Reply-To: <1733F2C0-324A-4C66-9904-F0B597271642@extremenetworks.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 2007-06-15 15:52, RJ Atkinson wrote: > Earlier, Brian Carpenter wrote: > % Also, this way you remove any security issues associated with DNS, > % and any confusion about IPv4 vs IPv6 connectivity to the servers. > > The *only* way to remove potential security issues associated > with DNS is to deploy DNS Security. Actually, not using DNS at all is another way, which is what I was suggesting for NERD. But security is the secondary issue; my primary issue is that it creates a potential for a circular dependency of routing on DNS and of DNS on routing, and I don't want Eliot to have to fly round the world rebooting the Internet on the day that circularity bites. I am definitely not satisfied by Eliot's rebuttal of this circularity risk. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 18 04:12: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 1I0CLX-0003BG-Ge; Mon, 18 Jun 2007 04:12:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0CLV-0003Ay-Ui for ram@iab.org; Mon, 18 Jun 2007 04:12:21 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0CLT-00040d-GN for ram@iab.org; Mon, 18 Jun 2007 04:12:21 -0400 Received: by ug-out-1314.google.com with SMTP id m2so1438198uge for ; Mon, 18 Jun 2007 01:12: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:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=gjiAe602at0vnzHZQ5hNv+3gXcn/XJmxiiUOKcPbNjya6dlMsV/UYw4XcQgEe5n34w2mAv5X1ZznkNCcVdgiJRKM3GI+TrqU/5VT5YqA1EfdVGPCB/xpO7UWg01nqClqDonUMIattr0nDJUAAvh6KqU81f0rCFHfE/3sbNhZUsI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=HNfcYj0PBQdHlhJ0oq3TbZrmPEfA5DnxFbE2cG1fk+cdURqmtfTliuIHCJBkGew+nZBRH60eCJF88k/vQFTFH7jGJNYrUnY9TaoVzM/Y6gVkJxbWX2ly5cxDzMGCSoOU0nOP+NkreFlDjf78Vd6GSiGz3kEuVem1QQz8x0JwzQg= Received: by 10.82.106.14 with SMTP id e14mr10696583buc.1182154338402; Mon, 18 Jun 2007 01:12:18 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id f6sm19423306nfh.2007.06.18.01.12.17 (version=SSLv3 cipher=RC4-MD5); Mon, 18 Jun 2007 01:12:17 -0700 (PDT) Message-ID: <46763E5F.4030500@gmail.com> Date: Mon, 18 Jun 2007 10:12:15 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [RAM] Ramblings about "locator" References: <20070615125013.D2E5C86AF7@mercury.lcs.mit.edu> In-Reply-To: <20070615125013.D2E5C86AF7@mercury.lcs.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Noel, On 2007-06-15 14:50, Noel Chiappa wrote: > > From: Brian E Carpenter > > > My original RAMble (sorry) ended thus: > > > Maybe the essential point is that a locator can at least in > > principle be mapped to topology and an identifier can't. > > My human-name can be mapped to a telephone number. My human-name is not, > however, a telephone number. An "identifier" can certainly be mapped to a > network location with the aid of the appropriate database, just as a DNS > name can be mapped to a network location. > > Maybe you're using the wrong word, and instead of "mapped" you really meant > something like 'directly related', or something like that, but the problem > is that that's a somewhat nebulous turn of phrase. Which is why I > previously suggested that nice gold-standard, easily-comprehendable tests > for 'does this name have location information embedded in it' are: Well, let me quote Schoch: >> At the time one wishes to communicate with a particular address, there >> will be some mechanism that will map an address into an appropriate >> route. >> >> The address (where something is) need not be bound to the route (how to >> get there) until this mapping takes place; the choice of an "appropriate" >> route may change over time. The thing is, Schoch didn't separate the loc and id aspects of addresses (after all, the whole point was a single logical addressing scheme for the whole catenet). So this issue we're discussing didn't arise. However, what he writes seems to me to apply to locators. > > - Do you have to get a new one when you move to a new location? > - Given two location-based names, can you tell, by comparing *just the > names*, whether they are 'close' to each other? > > Maybe someone else can come up with a snappy word/phrase which clearly, > cleanly and concisely embodies that very close relationship... > > > > A slightly different way to say it is that a locator is a handle for > > a route. > > No. My street address is not a handle (in any simple sense) for directions to > my house. Yes, with a lot of data (connectivity information), and a certain > amount of computing, it can be turned into directions, but the relationship is > not a simple one. True, but inside a RIB, a locator is definitely going to be what you use to find a route. Brian > > This was all quite clear a long time ago; see IEN-19, John Shoch, > "Inter-Network Naming, Addressing, and Routing", January 1978, now finally > available at: > > ftp://ftp.isi.edu/in-notes/ien/ien19.txt > > Everyone here should be familiar with what it has to say. > > Noel > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 18 05:46: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 1I0Do8-0001R6-3U; Mon, 18 Jun 2007 05:46:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Do6-0001QX-FQ for ram@iab.org; Mon, 18 Jun 2007 05:45:58 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0DnE-0004wh-Dv for ram@iab.org; Mon, 18 Jun 2007 05:45:06 -0400 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:45:03 +0100 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] Ramblings about "locator" Date: Mon, 18 Jun 2007 10:45:02 +0100 Message-ID: In-Reply-To: <46763E5F.4030500@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Ramblings about "locator" Thread-Index: AcexgGoHGkMmOOoiSWyGiMViA0EGbgADDfcA From: To: , X-OriginalArrivalTime: 18 Jun 2007 09:45:03.0471 (UTC) FILETIME=[586297F0:01C7B18D] X-Spam-Score: 0.2 (/) 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 A locator would be a point on a map - expressed in the same language as all other points on the map (x,y co-ordinates)? The map can be read to determine the route ? Louise -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 Sent: 18 June 2007 09:12 To: Noel Chiappa Cc: ram@iab.org Subject: Re: [RAM] Ramblings about "locator" Noel, On 2007-06-15 14:50, Noel Chiappa wrote: > > From: Brian E Carpenter >=20 > > My original RAMble (sorry) ended thus: >=20 > > Maybe the essential point is that a locator can at least in > > principle be mapped to topology and an identifier can't. >=20 > My human-name can be mapped to a telephone number. My human-name is=20 > not, however, a telephone number. An "identifier" can certainly be=20 > mapped to a network location with the aid of the appropriate database, > just as a DNS name can be mapped to a network location. >=20 > Maybe you're using the wrong word, and instead of "mapped" you really=20 > meant something like 'directly related', or something like that, but=20 > the problem is that that's a somewhat nebulous turn of phrase. Which=20 > is why I previously suggested that nice gold-standard,=20 > easily-comprehendable tests for 'does this name have location information embedded in it' are: Well, let me quote Schoch: >> At the time one wishes to communicate with a particular address, there >> will be some mechanism that will map an address into an appropriate >> route. >> >> The address (where something is) need not be bound to the route (how to >> get there) until this mapping takes place; the choice of an "appropriate" >> route may change over time. The thing is, Schoch didn't separate the loc and id aspects of addresses (after all, the whole point was a single logical addressing scheme for the whole catenet). So this issue we're discussing didn't arise. However, what he writes seems to me to apply to locators. >=20 > - Do you have to get a new one when you move to a new location? > - Given two location-based names, can you tell, by comparing *just the > names*, whether they are 'close' to each other? >=20 > Maybe someone else can come up with a snappy word/phrase which=20 > clearly, cleanly and concisely embodies that very close relationship... >=20 >=20 > > A slightly different way to say it is that a locator is a handle for > > a route. >=20 > No. My street address is not a handle (in any simple sense) for=20 > directions to my house. Yes, with a lot of data (connectivity=20 > information), and a certain amount of computing, it can be turned into > directions, but the relationship is not a simple one. True, but inside a RIB, a locator is definitely going to be what you use to find a route. Brian >=20 > This was all quite clear a long time ago; see IEN-19, John Shoch,=20 > "Inter-Network Naming, Addressing, and Routing", January 1978, now=20 > finally available at: >=20 > ftp://ftp.isi.edu/in-notes/ien/ien19.txt >=20 > Everyone here should be familiar with what it has to say. >=20 > Noel >=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 Mon Jun 18 06:06: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 1I0E7T-00057B-1d; Mon, 18 Jun 2007 06:05:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0E7R-00056u-Oi for ram@iab.org; Mon, 18 Jun 2007 06:05:57 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0E7O-0001CG-UJ for ram@iab.org; Mon, 18 Jun 2007 06:05:57 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 510EA59DA1; Mon, 18 Jun 2007 20:05:52 +1000 (EST) Message-ID: <467658F6.8020007@firstpr.com.au> Date: Mon, 18 Jun 2007 20:05:42 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Ivip (was ViP ...) References: <001201c7b178$5c2e0460$bc92f385@nictkafle> In-Reply-To: <001201c7b178$5c2e0460$bc92f385@nictkafle> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: Ved Kafle X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Ved, I agree with your summary of differences, except that with: > (1) types of addresses used to identify end hosts; (home > address vs. PI addresses) One way I am envisaging this is that the PI address space is really assigned (in a typically large subnet) to some central system which runs the Ivip system and that system splits it up into smaller subnets and individual IP addresses, which then become effectively PI for whoever the central system assigns them to. Alternatively, maybe an ISP or AS-end-user with PI space dedicates the space "Y" to the Ivip system. Then, it alone controls how that is mapped. Maybe it maps the whole subnet to a single ETR, which gives it portability (which it already has) or perhaps some other benefit. This doesn't really reduce the size of the BGP routing table, unless that subnet adjoins two other subnets which are already mapped via Ivip. Then, what was previously three entries in the global BGP routing table: X >> BGP mapped to all the ITRs in the world. Y >> BGP mapped to some border router on an edge network. Z >> BGP mapped to all the ITRs in the world. becomes a single entry: X } Y }>> BGP mapped to all the ITRs in the world. Z } This improves things for all the world's DFZ routers, and the owner of this PI space can do what they like with their Y space, changing the mapping, splitting it up etc. without causing any fuss whatsoever for all the world's non-ITR BGP routers. Most likely, the owner of the PI space will split up the mapping as it likes down to single IP addresses, and then use them as it wishes. Some it may use for its own purposes. Others it may assign to customers. In that case, the customer does not really have eternally portable PI space, because they still depend on the existence, management expertise, billing system etc. of the ISP or AS-end-user who owns the "master-subnet" Y, or the Y part of the larger "master-subnet" XYZ. But as long as they maintain good relations, the customer can use that IP address or subnet via whichever edge network they like, because the customer controls the mapping of their IP addresses or subnet. Also, with: > (2) where the mapping information is maintained in; (home > agent vs. ITR, ETR, TTR) The mapping information for Ivip or LISP is contained in a central, or perhaps distributed, database. For each IP address or subnet it is under the control of whoever the system has assigned that IP address or subnet to. In a mobile situation, or a multihomed situation, there may need to be rapidly executed changes of mapping, when one link fails for instance. There could be a number of systems which detect the changed situation and use automatic, cryptographically secured, access to the central database to change the mapping. The central database information is either pushed to ITRs or the ITRs have to pull the mapping, using a query and time-cached response system. Either way, the ITRs all over the world which are tunnelling packets have the same mapping information for this particular IP address or subnet. The ETR is not involved in the mapping at all. It just receives any IP-in-IP packet sent to it, and pops off the outer header to reveal the original packet. (Maybe it does something with hopcount.) If the ETR is a TTR for a 2-way tunnel to the mobile host, this TTR is still not directly involved in the mapping. Perhaps this TTR would have functions to control the central database mapping for this mobile host's IP address or subnet. However, I think it would be better for some completely different, system to do this. Then, if this particular TTR dies, that separate system can detect this and change the database's mapping (and therefore, within a few seconds ideally, the behavior of all the world's ITRs) to an alternative TTR with which the mobile device also has established a 2-way tunnel. Also: > (3) where tunnels start and where they end (home agents and > mobile host vs. ITR and ETR or TTR) being pernickety, I think someone reading this could think there is a 2-way tunnel tunnel between an ITR and an ETR or TTR. Mobile IP, as I understand it, apart from "route optimization" involves a 2-way tunnel between the mobile host and the home agent, or Mobile Anchor Point (MAP). I guess this may be encrypted and compressed, but not necessarily. The same kind of 2-way tunnel exists between an Ivip-mobile mobile host and its TTR. The mobile host may also have tunnels to other TTRs, but at any one time only one of them will be the TTR which all the ITRs are tunnelling (1-way) packets to. The Ivip mobile host must have its own IP address of some kind and it must establish this tunnel to the TTR. It somehow should choose one or more "nearby" TTRs, where "nearby" could mean totally different TTRs in geographically and topologically different parts of the Net, if the two links the mobile host are via different edge networks, such as one GSM-GPRS edge network and the other ADSL via NAT. In that case, the mobile host would have two separate edge-network-provided IP addresses it uses for tunnelling to its two TTRs. The tunnelling from ITR to TTR is purely 1-directional, unless the ITR also operates as the ETR in the reverse direction, which would be likely if this ITR/ETR is a border router. Assuming the correspondent host has an ordinary IP address, packets from it to the mobile host enter a 1-way tunnel from the ITR to the TTR. There, they pop out of the tunnel and are put into a separate 2-way tunnel to the mobile host. There is typically only one 2-way tunnel from the TTR to the mobile host. However, the mobile host can establish multiple tunnels via different edge networks (or even the same one, I guess) to that TTR, or more likely to other TTRs. There could be hundred or even thousand of ITRs at any one point in time tunnelling (1-way) packets to the currently active TTR for this mobile host. When the mapping in the database changes, all the ITRs will switch their 1-way tunnels to the new TTR. There will be a transition time, depending on how the ITRs do their updates, so ideally the mobile host will receive packets on all the tunnels it has to TTRs. Outgoing packets from the mobile host to the correspondent hosts will flow back along the 2-way tunnel to the TTR. Then, if they are addressed to ordinary (meaning direct BGP-reachable) IP addresses, the TTR will let them be carried by the ordinary BGP system to the correspondent hosts. If the destination address of a correspondent host is Ivip-mapped, the TTR may act as an ITR and encapsulate it, then let it be carried by normal means to the ETR which is currently the ETR for that correspondent host. (Except for when that ETR is the same router as this TTR.) So the flow of packets from correspondent hosts, left to right, to the mobile host MH1 is like this: [CH1]-----(ITR1)-------------(TTR1)~~~~~~~~[MH1] / | \ [CH2-ITR]--------(BR1)------/ | \~~~~~~~~[MH2] ETR / / [CMH3]~~~~~~(TTR2)----------/ CH1's packets are raw to ITR1, 1-way tunnelled to ITR1 and then 2-way ~~~~ tunnelled to MH1. CH2 has its own ITR encapsulation function, so there is a 1-way tunnel from it to TTR1 where it joins the 2-way tunnel to MH1. CHM3 has a 2-way tunnel to its TTR2, which sends on a 1-way tunnel to TTR1 where it joins the 2-way tunnel to MH1. Traffic back from MH1 to CMH3 goes on a 2-way tunnel to TTR1 and then on a 1-way tunnel in the opposite direction (so maybe it is a 2-way IP-in-IP tunnel) from TTR1 to TTR2. Then it goes on the 2-way tunnel to CMH3. Traffic between MH1 and MH2 is simply via two-way tunnels through TTR1. Traffic coming out of MH1 to CH1 or CH2 goes via a 2-way tunnel to TTR1. Let's say CH1 has an ordinary IP address. TTR1 simply pops the packets addressed to CH1 out and forwards them by the ordinary BGP system. In this example, CH2 has an Ivip-mapped address. It has its mapping set so all the world's ITRs' 1-way tunnel packets go to the ETR which is implemented at the Border Router BR1 of its edge network. In this example, I assume TTR1 also acts as an ITR, so it sends packets to CH2 via a 1-way IP-in-IP tunnel to BR1. BR1's ETR function pops off the IP-in-IP header and the local routing system is configured to forward the packet to CH2. This is a long-winded way of saying that I think your phrase: "where tunnels start and where they end" doesn't capture the fact that these are one, two or three different tunnels of different types in series, and some of them are 1-way tunnels converging on a single TTR. I figure you understand this, but I just wanted to point out that there isn't really a single tunnel, for instance, between CH1 and MH1. You wrote: > Let's think if Ivip can get benefits from Mobile IP experience, or > Mobile IP can get benefits from the Ivip idea. I am sure Ivip or similar can benefit from people who work with Mobile IP. I only have a cursory understanding of Mobile IP. With either LISP or Ivip, the ITRs are like a massive, steerable, set of reflectors which can beam packets to whichever ETR/MAP/TTR the destination host specifies, or which some other system decides should be used to maintain contact with the destination host. All that is needed there is an ETR function, and the ITR/Ivip system doesn't really know or care whether that is an ordinary ETR or a MAP/TTR. Mobile IP people probably dreamed of such a thing in the past, but didn't have the impetus to make it happen. The crisis in routing and addressing means that one or more global systems of ITRs are probably going to be built. The ITR system would enable Mobile IP to be Vastly(tm) more mobile and efficient because the mobile host can pick and choose dynamically between whatever TTRs suit it best as it moves. In my last message I wrote it would be good if host operating systems could perform the ITR functions of looking up mapping and encapsulating the host's outgoing packets. That won't work for most home or office desktop computers or internal servers, because they will be behind NAT. The outgoing packets will be to an ETR in the destination host's network and the packets in the return direction will be from the IP address of the destination host - so the NAT won't know how to rewrite the packet and forward it to whichever of its local hosts initiated the communication. Generally, I think it would be friendly if operating systems had an option to do these ITR functions, but first they need a reliable way of determining whether they are behind a NAT. I understand that ICE is the framework to do this within: http://tools.ietf.org/html/draft-ietf-mmusic-ice There are three circumstances where I think a host could and maybe should encapsulate its own outgoing packets: 1 - If it has an ordinary BGP-reachable IP address. 2 - If it has an Ivip-mapped address and is using Ivip-basic. 3?- If it has an Ivip-mapped address and is using a 2-way tunnel to a TTR (Ivip-mobile). However mobile devices may have long link delays, so it could take quite a while to get the mapping information, delaying the application programs packets from being sent, adding to storage requirements etc. Maybe, for any host using a TTR, it would be best to expect the TTR to act also as an ITR, since it probably has more memory and CPU grunt and has a much faster connection to the Net to make queries. (Ideally, the TTR's ITR function would have a full copy of the database.) Maybe I am thinking of the term "mobile" too literally. Generally speaking any host on a long-delay final link, such as a GPRS or worse, GSM data call (~1 second ping times...), especially a link which is congested or flaky, shouldn't be busying itself with looking up mapping information and encapsulating packets, which makes them longer. Also, the NAT device's outgoing packets might well be encapsulated by the NAT device - but only if that NAT device could be sure it was the outside layer of NAT. I don't think it matters whether the NAT device has its own normal BGP IP address, or whether it has an Ivip-mapped address - just as long as it is not behind a NAT itself. I hope Ivip/LISP encapsulation in ITRs, in hosts or in NAT egress ports themselves wouldn't upset STUN, TURN or ICE - all of which are having enough trouble dealing with the unknown and likely unpredictable behavior of one or more layers of suspected NAT. I guess that BEHAVE, RFC4787, which seeks to standardise NAT behavior, also needs to be considered. There are many scenarios to consider when trying ensure that a major architectural change such as we are considering won't be another can of worms like NAT. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 18 08:49: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 1I0GfN-0006Fz-Nd; Mon, 18 Jun 2007 08:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0GfM-0006Fh-Ni for ram@iab.org; Mon, 18 Jun 2007 08:49:08 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0GfL-0001IF-EA for ram@iab.org; Mon, 18 Jun 2007 08:49:08 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Jun 2007 14:49:04 +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 l5ICn4Kj005863; Mon, 18 Jun 2007 14:49:04 +0200 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp204.cisco.com [10.61.64.204]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5ICmxDR003979; Mon, 18 Jun 2007 12:48:59 GMT Message-ID: <46767F3A.6070803@cisco.com> Date: Mon, 18 Jun 2007 14:48:58 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [RAM] DNS usage in NERD References: <1733F2C0-324A-4C66-9904-F0B597271642@extremenetworks.com> <46763B92.9050200@gmail.com> In-Reply-To: <46763B92.9050200@gmail.com> 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=1593; t=1182170944; x=1183034944; 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]=20DNS=20usage=20in=20NERD |Sender:=20; bh=56kI0V/TqoggOT0JLw/IJ5b9/3WElFgvsXut5YWUR7k=; b=OzKJrQ06ZHS0TSUdGLBreL+v80P6Q6SdQpt3JnyjnHOdaOWuzJmUwc5dah9hjRFeAa7/kVzI MuF1Jd8OeQ9eJfb2PvJUKvpF36/6t+YjldUEZPCZlLhN2KMWa+TCFZWX; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Brian E Carpenter wrote: > On 2007-06-15 15:52, RJ Atkinson wrote: >> Earlier, Brian Carpenter wrote: >> % Also, this way you remove any security issues associated with DNS, >> % and any confusion about IPv4 vs IPv6 connectivity to the servers. >> >> The *only* way to remove potential security issues associated >> with DNS is to deploy DNS Security. > > Actually, not using DNS at all is another way, which is what I > was suggesting for NERD. Well, it's possible to do this but IMHO not desirable. For one thing, you would need some sort of distribution point to pull from, and everyone would have to know about it. It's best for that to be a name so that the address can change, but it could just as easily be an address. N.B., as discussed in the draft, this doesn't mean that you need to use it every time. It might be that your neighbor can feed you the database or that you can pull it off of some p2p network, but if you can't you need some place to get it authoritatively. > But security is the secondary issue; > my primary issue is that it creates a potential for a circular > dependency of routing on DNS and of DNS on routing, and I don't > want Eliot to have to fly round the world rebooting the Internet > on the day that circularity bites. I am definitely not satisfied > by Eliot's rebuttal of this circularity risk. You are also perfectly free to resolve the name on your system and use the resulting IP address. However, if the dependencies do not make use of LISP or NERD there is by definition no dependency loop. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 18 08:55: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 1I0GlC-00074b-Hz; Mon, 18 Jun 2007 08:55:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0GlB-00074W-QD for ram@iab.org; Mon, 18 Jun 2007 08:55:09 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0GlA-0002ab-C7 for ram@iab.org; Mon, 18 Jun 2007 08:55:09 -0400 Received: by ug-out-1314.google.com with SMTP id m2so1481252uge for ; Mon, 18 Jun 2007 05:55:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=AiJ/wKDnrcZKkAC5H0h0ck00VC780HnoNFdO6uKVO2FMZIX3baAqzI+69iKUTkbviGXpYZfflkPwhNRU7pGVZdUET7SSxy0YdG/PEYMFTPyS+LGTpCl3tJnZkHIKsDsJSKn3aWrg//TzKXTWj8gE4Ul8IqtQiLvnzvWTEgieaDI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=nUR34oa7Gp2dRSRB2Ww5JdiezjRhdFmvEKNNC2uMuyIGbovSLQw3uxeebIa9JGx76PSXQbEbIQfpFFtR1rnbzm+H9eEZyVgOTmP8vPBG01tBf68BlO8XSw2nqeIenwp2TkHIxH4Cmz5Fwzgn/AsEhK361e3p9gXvxWg1vrNBomQ= Received: by 10.67.102.16 with SMTP id e16mr5031698ugm.1182171306501; Mon, 18 Jun 2007 05:55:06 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id 61sm4903851ugz.2007.06.18.05.55.05 (version=SSLv3 cipher=RC4-MD5); Mon, 18 Jun 2007 05:55:06 -0700 (PDT) Message-ID: <467680A7.7070305@gmail.com> Date: Mon, 18 Jun 2007 14:55:03 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [RAM] DNS usage in NERD References: <1733F2C0-324A-4C66-9904-F0B597271642@extremenetworks.com> <46763B92.9050200@gmail.com> <46767F3A.6070803@cisco.com> In-Reply-To: <46767F3A.6070803@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 are also perfectly free to resolve the name on your system and use > the resulting IP address. However, if the dependencies do not make use > of LISP or NERD there is by definition no dependency loop. Indeed, but how can you impose a constraint that DNS zone transfers etc do not in any way depend on NERD/LISP? That is where I am puzzled. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 18 09:08: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 1I0Gxn-0004Gb-Nv; Mon, 18 Jun 2007 09:08:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Gxm-0004GU-SY for ram@iab.org; Mon, 18 Jun 2007 09:08:10 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Gxk-0006BW-FY for ram@iab.org; Mon, 18 Jun 2007 09:08:10 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 69C10212F31; Mon, 18 Jun 2007 16:08:07 +0300 (EEST) Received: from [127.0.0.1] (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 2E47F212DF2; Mon, 18 Jun 2007 16:08:07 +0300 (EEST) Message-ID: <467683B6.2000602@ericsson.com> Date: Mon, 18 Jun 2007 16:08:06 +0300 From: =?ISO-8859-1?Q?Mikko_S=E4rel=E4?= User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] Re: Ramblings about "locator" References: <20070614193023.A2F2387361@mercury.lcs.mit.edu> <8A7E8D43-1C74-4466-A6ED-124D47043B05@extremenetworks.com> In-Reply-To: <8A7E8D43-1C74-4466-A6ED-124D47043B05@extremenetworks.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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 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 RJ Atkinson wrote: > > On 14 Jun 2007, at 15:30, Noel Chiappa wrote: >> I have a hard time figuring out what "locator" means >> to you all if you think a MAC address is a locator. > > Noel, > > You were the person who persuaded me, after some > resistance on my part, that since the IEEE MAC address > is used in a lookup table (either a bridge table or an > IPv6 ND table) to forward the frame/packet, therefore > the MAC address must have location semantics and so > could not be a pure Identifier. Names such as MACs can be used to point to a location in the network topology. However, the important question is not whether they can be used, or even if they are used for such a thing. The important distinction between two types of names is whether the names themselves carry topological significance. In the case of IP addresses, the name itself carries topological meaning. In the case of MACs the names carry no topological meaning. The network, however, uses those names to make a map of the network topology. The difference between these two cases is that in the former, the name itself carries part of the topological information, where as in the latter all the information resides in the bridge. -Mikko _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 18 09: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 1I0HJj-0002A7-NQ; Mon, 18 Jun 2007 09:30:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0HJi-00029x-GN for ram@iab.org; Mon, 18 Jun 2007 09:30:50 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0HJg-0004ax-UK for ram@iab.org; Mon, 18 Jun 2007 09:30:50 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 67EF359DA1; Mon, 18 Jun 2007 23:30:42 +1000 (EST) Message-ID: <467688F8.4000402@firstpr.com.au> Date: Mon, 18 Jun 2007 23:30:32 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] DNS usage in NERD References: <1733F2C0-324A-4C66-9904-F0B597271642@extremenetworks.com> <46763B92.9050200@gmail.com> <46767F3A.6070803@cisco.com> <467680A7.7070305@gmail.com> In-Reply-To: <467680A7.7070305@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: RJ Atkinson X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Brian wrote: > Indeed, but how can you impose a constraint that DNS zone transfers > etc do not in any way depend on NERD/LISP? That is where I am > puzzled. Wouldn't it be good enough that LISP/Ivip or whatever states in its architectural RFC that addresses which depend on this mapping scheme should not be used for certain purposes, including?: 1 - BGP routers, including ITRs and ETRs - obviously. 2 - Root and TLD nameservers. Probably many second level nameservers such as .com.au. too. Probably including any nameserver which does something under in-addr.arpa on which anyone else's but the operator's addresses depend upon for reverse mapping. 3 - Any nameserver on which the mapping scheme depends. 4 - Whatever central database servers control the mapping system, including interfaces for user control of mapping of their IP addresses, servers for all push and pull update activities and any independent systems which monitor where a mobile host is connecting, and automatically initiate changes to the mapping database if the mobile host's current link fails. Then all the critical nameservers have ordinary BGP-accessible addresses, so their zone transfers go via ordinary BGP, irrespective of what the mapping system does. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 18 11:07: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 1I0Iom-0006Xj-Js; Mon, 18 Jun 2007 11:07:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Iol-0006XX-IR for ram@iab.org; Mon, 18 Jun 2007 11:06:59 -0400 Received: from [2001:470:1:1:230:48ff:fe74:fd02] (helo=bender-mail.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Ioj-0000vF-4Y for ram@iab.org; Mon, 18 Jun 2007 11:06:59 -0400 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 38F477DCA for ; Mon, 18 Jun 2007 08:06:56 -0700 (PDT) Received: from JMHLap3.joelhalpern.com (jupiter.inet.qwest.net [67.133.255.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id A82267DAB for ; Mon, 18 Jun 2007 08:06:55 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Jun 2007 11:06:51 -0400 To: From: "Joel M. Halpern" Subject: RE: [RAM] Ivip (was ViP ...) placement In-Reply-To: <001201c7b178$5c2e0460$bc92f385@nictkafle> References: <46751FC2.30804@firstpr.com.au> <001201c7b178$5c2e0460$bc92f385@nictkafle> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070618150655.A82267DAB@bender.tigertech.net> 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=1.8 tagged_above=-999.0 required=7.0 tests=FORGED_RCVD_HELO, MSGID_FROM_MTA_ID X-Spam-Level: * X-Spam-Score: 1.8 (+) 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 The note on the list comparing lvip with Mobile IP suggested a question in my mind. In LISP. the TR (the device provides I and E functionality) is providing service directly to a specific set of customers. Its capacity is tied to those customers, and it is operated either by those customers or by the ISP associated with those customers. If we assume that there is value in having this, one can envision how the capability gets paid for. If there is a rendezvous point somewhere off in the net, advertising a short prefix, and then disagregating that prefix into tunnels, that device is operated by someone. But that someone is not the customer whose blocks are being advertised, nor is it the ISP serving those customers. This leads to both authentication questions (how do you know this rendezvous box is allowed to issue that advertisement) and business model questions (how does it get paid for? While conceptually decomposing the devices and separating the deployment is attractive, I fear that there are issues raised by such a separation that require attention. Yours, Joel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 19 01:39: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 1I0WRR-0001Ed-IV; Tue, 19 Jun 2007 01:39:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0WRP-0001CF-W6 for ram@iab.org; Tue, 19 Jun 2007 01:39:47 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0WRL-0004qW-HB for ram@iab.org; Tue, 19 Jun 2007 01:39:47 -0400 Received: from [10.0.0.9] (dell.firstpr.com.au [10.0.0.9]) by gair.firstpr.com.au (Postfix) with ESMTP id CB2E259DA1; Tue, 19 Jun 2007 15:39:40 +1000 (EST) Message-ID: <46776CCD.4010504@firstpr.com.au> Date: Tue, 19 Jun 2007 15:42:37 +1000 From: Robin Whittle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Ivip (was ViP ...) placement References: <46751FC2.30804@firstpr.com.au> <001201c7b178$5c2e0460$bc92f385@nictkafle> <20070618150655.A82267DAB@bender.tigertech.net> In-Reply-To: <20070618150655.A82267DAB@bender.tigertech.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9361ae25efd9cff62e36f70ef966350e 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 This is another long "thinking-aloud" brainstorming message, concerning where ITRs would be, who would run them and pay for them, how Ivip might be introduced as a single system, whether RIRs should allow ASNs to use their assigned space for Ivip systems which are separate from the main one etc. Hi Joel, You wrote: > The note on the list comparing lvip with Mobile IP suggested a question > in my mind. > > In LISP. the TR (the device provides I and E functionality) is providing > service directly to a specific set of customers. Its capacity is tied > to those customers, and it is operated either by those customers or by > the ISP associated with those customers. If we assume that there is > value in having this, one can envision how the capability gets paid for. By "TR" I think you mean "Tunnel Router" - I guess a router which also provides LISP ITR and ETR functions. These functions don't have to be on the one router. These LISP ITR/ETR routers could be internal routers and/or border routers. Theoretically the whole edge network could be served by the ITR/ETR functions being implemented solely a the border routers. For scaling purposes, it might be better to have ITR functions in routers carrying packets towards the border routers, and to do the decapsulation ETR work in those or in other internal routers. In all cases, these functions can only be used by hosts which are part of, or which connect to the net through, that edge network, so this generally solves the question of who pays for it: the users of the edge network. > If there is a rendezvous point somewhere off in the net, advertising a > short prefix, and then disagregating that prefix into tunnels, that > device is operated by someone. But that someone is not the customer > whose blocks are being advertised, nor is it the ISP serving those > customers. This leads to both authentication questions (how do you know > this rendezvous box is allowed to issue that advertisement) and business > model questions (how does it get paid for? > > While conceptually decomposing the devices and separating the deployment > is attractive, I fear that there are issues raised by such a separation > that require attention. Regarding authorisation, I will first try to correct my earlier confusion about anycasting. I am now sure that what I am suggesting for Ivip ITRs really is "anycasting", although a little different from the usual approach. I understand that ordinary anycasting in the BGP system involves multiple BGP routers all over the world advertising a particular subnet, let's say 11.0.0.0/24. Then, each such router sends the packets it receives which are addressed to this subnet to local hosts which have these IP addresses. Those hosts accept each packet and generate a response packet, which the BGP router handles normally and forwards via the global BGP system to the correspondent host which sent the initial packet. This works fine for UDP single query-response systems, such as DNS queries. It is not normally used for TCP sessions, since the correspondent host might at various times have its packets forwarded to multiple such anycast routers. Ivip uses the same anycast BGP advertisements. So whatever current authentication or policing arrangements work for BGP anycast - I don't know if there are any - might work for Ivip's ITRs. The difference between DNS anycast and Ivip's anycast approach is that packets received by ITRs all over the world are always tunneled to the same ETR and so arrive at the one physical host which has that IP address. This means it will work fine for TCP, as far as I know. Maybe there could be flaky situations in which the path taken by packets from the correspondent host fluctuates to direct them to two or more ITRs, with one ITR having a much longer path to the ETR. Then, there could be some out-of-order packets. But the Internet doesn't guarantee in-order packet delivery, and in most situations I guess that the packets would flow to a single ITR in any one period of time such as 0.2 to 2 seconds. The business question of who will pay for public-access ITRs outside edge networks only applies to Ivip's ITRs. As with LISP, ordinary (Ivip-basic) ETRs are only located at the border routers or internal routers of edge networks and can only successfully decapsulate packets and have them forwarded to the hosts with Ivip-mapped IP addresses as long as the host is in that network (and so pays the owner of the network), as long as the edge network routing system knows how to route the packets to the host, and as long as the assignee of that Ivip-mapped IP address or subnet has configured the central database to map packets to this ETR. I will leave the question of TTRs which act as EARs for Ivip-mobile out of this discussion, except to say that I envisage there being multiple companies operating such systems of TTRs, with mobile hosts needing to authenticate themselves before being able to use their services, which the operators of the mobile hosts, who are the assignees of the Ivip-mapped addresses, would need to pay for. ETRs probably don't need to be coordinated in any way - but maybe there could be some protocol for asking them to report on connectivity with the host for a particular IP address. At a minimum, a TTR must act as an ETR and as an ordinary BGP router for egress of packets. As such, it needs one or a few normal IP addresses. It doesn't take up large amounts of address space, as the Ivip ITR system does. A TTR may well integrate an ITR function, as I mentioned in my previous message. I figure a single global Ivip system would allow anyone to run an ITR function, provided they complied with a set of rules, such as always correctly tunnelling the packets it receives, using the most up-to-date mapping information etc. Before discussing the question of who pays to run ITRs, I want to think more about terminology and situations with the end-user whose IP addresses are mapped by the Ivip network. I will try using the term "assignee of an Ivip-mapped address" to refer to whoever has the effective authority to control the mapping of a single IP address or a subnet (prefix) within the Ivip system. Here are some examples: 1 - One of the many "master-subnets" handled by the Ivip system is 11.11.0.0/16. This was assigned by an RIR as PI address to company Z. Company Z is the assignee of this subnet (AKA prefix) in RIR terms. Company Z has registered with the central "Ivip Authority" - whoever controls the database which controls the ITRs - for simplicity I am assuming a single Ivip system. There could be multiple systems, in which case company Z may have registered with the VVV Ivip network. In either case, company Z has told the Ivip system that all that system's ITRs should advertise 11.11.0.0/16 on all its with those ITRs tunnelling the packets however company Z chooses. Company Z has authenticated access to the control interface for the database, so one or more people or hosts under company Z's control are physically able to alter the contents of the database, and so have complete control over how the ITRs tunnel packets sent to 11.11.0.0/16. Company Z could have these 65,536 IP addresses mapped in various ways: a - The whole subnet could be tunneled to a single ETR. b - The subnet could be split and tunneled to multiple ETRs as somewhat smaller subnets. c - The subnet could be split, potentially into individual IP addresses, each to be tunneled to an independently chosen ITR. In all cases, company Z could do this for its own internal purposes and/or it could use this address space partially or wholly for its customers. If some or all of the subnet is assigned to customers, then presumably those customers are paying for this service. If the Ivip system involves fees, then Company Z needs to pay those fees and presumably collect fees from any customers. In order for this to be useful for the customers each customer needs some way of controlling which ETR their IP address(es) or subnet(s) are mapped to. This could be by company Z having its own user interface system which its customers use, via various interfaces including a web page for manual configuration, or some protocol interface for automated operation. Company Z's system would convey all changes immediately to the central Ivip database. Company Z may also run a system which checks connectivity of its customers who want multihoming, and switches the mapping of their address(es) to another ETR if their host or router can't be reached via the ETR which packets are currently being tunnelled to. An alternative would be that company Z tells the "Ivip-authority" that until further notice, its customer AA should be authorised to directly control the mapping of one or more IP addresses, subnets etc. within 11.11.0.0/16. This enables customer AA to have faster, more direct, control of the mapping of the IP addresses they have been "assigned" by company Z. In this case customer AA would be the "assignee". Customer AA probably doesn't have an ASN or know what BGP is. Customer AA has no relationship with an RIR. It depends entirely on the stability and continued good relations with company Z for its continued use of this IP address space. If company Z has physical control of the mapping of customer's AA addresses, but is doing so entirely as customer AA desires, then I would still call customer AA the "assignee". This is all sounding rather legalistic... 2 - The Ivip system itself may have been assigned PI space by an RIR. Then, it can assign control (presumably for some kind of fee) to end-users for any one, two or up to millions of IP addresses. These do not necessarily need to be ordinary prefixes or on binary boundaries. There is no concept of route-aggregation in this Ivip-mapped space. The Ivip system could advertise hundreds or even thousands of "master-prefixes". Some could be directly assigned by RIRs or others could be assigned by AS-end-users or ISPs which had this space assigned to them by RIRs. If the Ivip-authority assigns 33.33.27.64 - 33.33.29.16 to company N, company N is the "assignee" of these addresses. If company N assigns 33.33.28.80 to 33.33.28.87 to company M, then company M is the assignee of these 8 addresses. So there are various ways by which the end-user assignee could have gained their addresses. They may be assigned directly from an RIR and then the end-user authorises the Ivip system to advertise and map them. The Ivip system may be assigned PI space and then rents it out, assigns it or whatever to other companies or end-users. An end-user may get their space via a chain of RIR > Ivip-authority > wholesaler 1 > retailer 2 > final end-user. Let's say the RIRs collectively create, or act as a single Ivip-authority. While there may also be commercial or independent Ivip systems, those systems are only going to be of value if they have lots of well-located ITRs. For the moment, let's assume that the single global Ivip-authority system is so successful that no-one tries to set up their own. I will try to imagine a stable state of widespread Ivip usage, then try to imagine how a single system could develop into that state incrementally. Let's say the Ivip-authority had enough funding to run a centralised database server which was capable of sending updates to ITRs, either by push or by pull methods, and a basic user interface of manual web-based configuration and direct protocol interfaces for automated systems to control the mapping of one or more IP addresses or subnets. I know virtually nothing about the finances and business arrangements of RIRs, domain name authorities, commercial domain name registers and the root, TLD and major second-level name servers. I figure the whole system is paid for largely or wholly by the fees we pay to register domain names. Assuming a single Ivip system without any competitors, I guess there would need to be some similar commercial reseller system for IP addresses, similar in some ways to that for domain name registrations, and probably involving the same companies. However, I hope that the demand for Ivip-mapped addresses would be for a smaller subset than the mass-market, whole of business and organisational and personal-domain-name humanity, which the domain-name business serves. Hopefully, most people wouldn't need to worry about the nature of the IP addresses they use for home and small office access. Hopefully, Ivip-mapped addresses will be managed by end-users (or their network managers or ISPs) with genuine needs for portability, multihoming and TE etc. Also, these are just numbers, not names, so hopefully the whole thing would be more technical, less marketing driven etc. than the domain-name business. I feel sure there will soon emerge some kind of market-based system for deciding who has IP addresses, because when fresh supplies run out, the RIRs won't want to handle the endless disputes and requests about who should have space, when some ISPs or AS-end-users have large slabs of space which they appear not to be using efficiently, or perhaps at all. With a market, that space would either be returned to the RIRs or sold or rented out or whatever. There may well be a commercial market for addresses within the growing proportion of addresses which are mapped via Ivip or whatever. This may be quite separate for whatever commercial arrangements develop for raw directly BGP-routed space, in 256 IP address increments, as currently assigned by RIRs to ISPs and AS-end-users. Competing systems of ITRs, each operated by a company and renting out the mapping of its IP addresses, could only persist as long as at least one RIR considered this to be a legitimate use of the space it had assigned. Normally, I understand, RIRs assign space according to projected need of an ISP or AS-end-users - need for space in their own physical networks. A company or organisation running an Ivip system is not running a physical network. They would be engaging in the currently unprecedented practice (I think) of having a bunch of anycast routers all over the Net, for the purpose of tunnelling packets one-way to one or probably numerous edge networks, usually not their own. So I think it is probably a matter of IANA/RIR policy whether there will ever be multiple Ivip systems. I imagine this stable, very widely used Ivip-authority single Ivip system of ITRs being made up of ITRs and various other things which are not operated by the Ivip-authority itself. The Ivip-authority would be running something like the first levels of the DNS. There would be millions or billions of IP addresses under its control. Many of them would have stable mapping which would only change every few years. Some might have mappings which change every few minutes, as a mobile device takes its packets through different TTRs. Maybe the Ivip-authority charges for its services partly by: 1 - Total number of IP addresses. 2 - Total number of changes, where a single change can apply to a large number of IP addresses, according to whatever physical protocol is used to send the changes to the ITRs. So changing the mapping of 32 randomly distributed IP addresses would be charged as 32 changes, but only as one change if it was a contiguous set of addresses which could be specified in a single change message. 3 - Also, perhaps, by the number of queries it receives for these addresses via any "pull" system it operates - but this is open to abuse by hackers who want to bankrupt an assignee of an Ivip-mapped address. There are some significant scaling problems and questions of commercial cost in any such system. Let's say that most edge-networks perform their own ITR functions. They do this to remain competitive, since the alternative is relying on ITRs out in the DFZ. These may involve longer paths or dropped packets due to being overloaded. This would be ironic: LISP ITR's must be in internal routers or border routers. LISP is never attempted because no-one wants to be the first to use LISP-mapped addresses while most edge-networks have no ITRs. Ivip is launched instead, with an initial seeding of ITRs in the DFZ. After a significant amount, say 20% of traffic, flows to Ivip-mapped addresses, pretty much every edge network has its own ITRs. So Ivip winds up resembling LISP, in many respects! Ivip's only two real differences from LISP are: 1 - Mapped addresses are advertised in BGP. 2 - ITRs can be in the DFZ, using anycast. (Someone would have thought of these sooner or later. My idea of using Ivip ITRs to beam packets to freely chosen TTRs for Ivip-mobile is equally applicable to LISP and would have been seized upon by anyone thinking about LISP and mobile IP at the same time. My idea of how LISP or Ivip should be used may differ from how others think about it, and I have written more expansively/ramblingly and given some diagrams, maybe more concrete examples etc., without a large number of variants numbered to two decimal places.) With ubiquitous adoption, there wouldn't be a lot of difference between LISP and Ivip. But the fact (I think) that Ivip could be adopted, and that it could continue to work with a handful of non-upgraded edge networks, is a vital distinction. Very roughly, here is how a single global Ivip system might be developed. Please excuse my probable ignorance of how the various organisations work together. 1 - IETF develops protocols, standards etc. 2 - IANA and RIRs decide that a single Ivip system needs to be established, and that anyone using address space for their own Ivip system is not using it in accordance with prevailing policies. 3 - ICANN, IANA, RIRs and maybe peak organisations of domain name resellers set up some new authority to run the database. 4 - A handful of transit providers promise to run ITRs around the world to get the system going and to support, in the long term, edge networks which don't provide their own ITRs, although that service would probably be slow. (Maybe there is a peak body of transit providers and major telcos/ISPs who could commit their members to providing some level of ITR support. This would cost money, but by this time, Ivip or whatever would be seen as the best or only hope of containing the growth in the BGP routing table which is threatening to make all their routers obsolete.) 5 - In the light of the Ivip alternative, maybe the RIRs develop some policies about the addresses they assign for normal BGP use, how assignees are expected to use that space without excessive numbers of changes etc. Also, there may need to be some new policies about RIRs assigning large slabs of address space to the Ivip system. The more space, and the fewer the divisions between its contiguous divisions, the fewer BGP advertisements will be needed. The ISPs and AS-end-users could install ETRs and organise their internal routing systems to cope with the various Ivip-mapped IP addresses or subnets in their edge networks. This shouldn't cost much, and only needs to be done by edge networks where customers or internal users will want to locate hosts with Ivip-mapped IP addresses. ITR capabilities in routers could be developed. As a low-cost alternative, it might be possible to develop open-source software for a dedicated ITR box, such as a 64 bit Linux box with a 1G or 10G interface. This can do nothing but be a BGP advertiser for the Ivip "master-prefixes" and send the encapsulated packets back on the same Ethernet cable. This "stub-ITR" could be built for a few thousand dollars and plug into an interface of any router, to make that router effectively an ITR. Load balancing could be done by having multiple boxes, each advertising a subset of the Ivip system's "master-prefixes". If existing routers couldn't do the ETR function, there could be a similar Linux box with open-source software for that too. This would greatly ease the adoption costs for many ISPs and edge networks. After a few years, router vendors would implement ITR and ETR functions as standard in routers - so the ITR function would migrate into real routers as part of the standard upgrade cycle. Ivip's ETR functions (not counting TTRs, which may be outside or inside edge networks) must be implemented either at border routers and/or internal routers. In either case, as with LISP, it is clear that the users of those ETRs will pay their ISP in some way for traffic which flows through those ETRs. I think the ETR cost could be low, since they don't require a database, don't require authenticated access or maybe any management at all. It may be as simple as having a bunch of routers in the network, including the border routers, all providing ETR functions, and giving advice to users inside the edge network about which ETR they should best map their Ivip-mapped IP address or subnet to. If Ivip became ubiquitous, then as for LISP, I think most of the edge networks would implement their own ITR functions, at internal and/or border routers. This would provide their users with the best performance, because the ISP could guarantee that all packets generated in the edge network for Ivip-mapped IP addresses would be locally encapsulated, removing any dependence on external ITRs. Lets say that Ivip ITRs are widely deployed in most edge networks and many users depend on Ivip-mapped IP addresses. Any hosting company with a proportion of their servers using Ivip-mapped addresses (I am not sure that this is a justifiable use of Ivip - there's nothing wrong with web servers using PA addresses from whatever hosting company they are sitting is and having the customer's nameserver point to that address) will want to ensure those servers are reachable via any edge network, including those with no internal ITRs. The hosting company could do this by making their border routers act as ITRs. They could also plant an ITR just outside their network. The ITR, in both cases, I assume would have to advertise the complete set of "master-subnets" which the single global Ivip scheme advertises. (If there were multiple such schemes, the hosting company's ITR would need to implement ITR functions for the "master-subnets" of every such scheme for which some edge networks did not themselves implement ITRs.) An ITR should, I think, not just accept all incoming packets for the "master-subnets" it advertises, but properly handle them by tunneling them to whichever IP address of an ETR which they are currently mapped to. It would be unfriendly and disruptive to have an ETR advertising the whole set of "master-prefixes" but dropping all packets which were not to be tunneled to the hosting company's ETRs. I wonder how disruptive this would actually be, however. The hosting company could say: "If these packets found their way to our border router, or our nearby outrigger ITR, then firstly they came from edge networks which were not equipped with ITRs and secondly those edge networks were deficient in these nearly ubiquitous Ivip times by not ensuring there was an upstream ITR." I am trying to find a long-term reason why an ISP, hosting company, transit provider or AS-end-user would want to run an ITR in the DFZ in the long term. Someone needs to do this, but to provide a "second-best" service so as to encourage edge networks to install their own ITRs. Probably the transit providers are the best placed to run these ITRs. But why should they do so? Initially, they might volunteer to do so in order to get Ivip off the ground, since the rising tide of the BGP routing table will be making them fearful. Initially, the Ivip-authority could run a few ITRs to get the system going. A commercially run Ivip system would either run its own ITRs and/or pay others, such as transit providers, and ISPs, to run the ITR functions on their own routers. If there were multiple such commercial systems operating with compatible ITR <-> database pull or push protocols, then ISPs might have a single router which runs the ITR functions of multiple commercial Ivip systems on, charging each such system a fee for the traffic volume. The commercial Ivip systems would generate revenue by charging their customers according to IP addresses assigned, the number of changes made to the mapping, and the volume of packets forwarded. I am not sure if independent Ivip systems are a good idea. My sense is that they are not, as long as a single centrally run Ivip system is well run. Transition to a major new architecture requires a lot of thought. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jun 20 14:37: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 1I153G-0001IR-F6; Wed, 20 Jun 2007 14:37:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I153F-00014d-3f for ram@iab.org; Wed, 20 Jun 2007 14:37:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I153E-0001Ut-Hr for ram@iab.org; Wed, 20 Jun 2007 14:37:09 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 20 Jun 2007 11:37:03 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAG8QeUarR7PEh2dsb2JhbACPHgEBAQgOLA X-IronPort-AV: i="4.16,443,1175497200"; d="scan'208"; a="163557324:sNHT154228806" 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 l5KIb3hu028147 for ; Wed, 20 Jun 2007 11:37:03 -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 l5KIb0aI021558 for ; Wed, 20 Jun 2007 18:37:03 GMT Received: by vaf-lnx1.cisco.com (Postfix, from userid 113818) id 9E4B13D80AF; Wed, 20 Jun 2007 11:35:47 -0700 (PDT) Date: Wed, 20 Jun 2007 11:35:47 -0700 From: Vince Fuller To: ram@iab.org Message-ID: <20070620183547.GA24174@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7115; t=1182364623; x=1183228623; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20 |Subject:=20Preliminary=20thoughts=20on=20LISP=201.5 |Sender:=20; bh=gAPRjy5VPLm3tIUW4uffr2DKJqRLFA9/fVDiB3UHK7U=; b=kFXRq9Rso7joq9zDyxqr80vfdSvFMEdIejASRKy3LImWBmAO7MthZeuVSVNykHRAZlSwIWLf i2mOngmmCfiYIJ17VvwOtRCB1HAyU3pbuD4kbDXwvcAmFKMQbJJqghaS; Authentication-Results: sj-dkim-4; header.From=vaf@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Subject: [RAM] Preliminary thoughts on LISP 1.5 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 there seems to be some ongoing discussion of LISP and whether or not it is incrementally deployable, I thought I'd share the following message which I wrote to a smaller discussion group about two months ago; it sketches out some ideas on how a LISP 1.5 infrastructure might offer a hybrid push/pull model, where highly-aggregated EID prefixes would be "pushed" into a global infrastructure while information about specific destinations of interest to a particular source would be "pulled" in a data-triggered manner using LISP 1.0 protocol machinery. The LISP authors plan to write-up a more complete Internet Draft describing this approach but here are some conceptual ideas. --Vince -------------------- Date: Wed, 4 Apr 2007 09:54:41 -0700 From: Vince Fuller Subject: Re: Cache ... > > The thinking here was that the ITR could be co-located with a local > > DNS caching server, and have all of the hosts served by an ITR use > > that same system for DNS lookups. > > That strikes me as a set of extremely unrealistic deployment constraints. Note that this approach is specific to LISP 2 and resresents some thinking on how one would improve EID-to-RLOC setup latency when a mapping doesn't exist for a particular destination. > > There are obvious ways of attacking the rate * state product. You > > can decrease the rate by distribution. You can decrease the state > > by going to a pull model. > > The most obvious way of reducing the amount of data is by aggregation, of > course. I guess we're looking for alternative methods that don't introduce > enormous amounts of complexity. Well, I hope we're wishing ourselves luck > ;-) > > Certainly if you distribute the data so that it is never all in one place, > you improve the per-box scalability, since each box has less to worry > about. Of course, you might end up needing more boxes. It's never been > clear to me whether a solution which increases the number of boxes rather > than the size of each box would be considered as "solving the problem". > > To first order, I don't think that "pull vs. push" is an important > distinction, since it leaves open the question of where you're pulling from > and whether that is scalable. Also, if you distribute the data, you don't > necessarily need a pull model, you just need to make sure that the data > paths take each packet through a place where the appropriate data can be > found (i.e., if the addressing doesn't follow the topology, make the > topology follow the addressing). This approach is similar to some thoughts that I've had on how an EID-to-RLOC overlay topology might be structured for LISP 1.5. The idea is roughly as follows: 1. Assign EID prefixes according to some hierarchy that bears only rough resemblence to the actual Internet topology. An RIR, exchange-point, or geographic hierarchy is probably good enough here. One that approximately follows DNS delegations would also work. It is probably even possible to construct a hybrid of more than one of these, at a cost of requiring a larger number of "top level" EID prefixes. 2. Build an overlay topology of EID-to-RLOC "LISP translation aggregators" (LTAs) which matches the hierarchy in (1). This topology may contain one or more layers of aggregation, depending on size and scope. LTAs are interconnected by tunnels in a topology that is isomorphic with the prefix assignment hierarchy, with redundancy. 3. For each ETR that holds an authorative EID-to-RLOC mapping for a prefix, configure one or more tunnels to the LTAs which can aggregate that prefix with others at the same point in the assignment hierarchy. The ETR advertises the existance of that EID-to-RLOC mapping using some protocol (BGP, with a separate AFI/SAFI for LISP would work). 4. LTAs aggregate and propagate mappings "upward" toward the root of the assignment hierarchy. 5. For each ITR, confgure one or more tunnels to LTAs. The LTAs advertise the aggregated EID-to-RLOC mappings to the ITR over the tunnel(s). Exactly which LTAs a particular ITR uses depends on the level of detail about the global EID-to-RLOC mapping database that it wishes to have "pushed" to it (again, consider BGP with a separate AFI/SAFI for LISP). The LTAs may advertise (or an ITR may/could/should confgure) a "default" mapping if it wishes to be able to do EID-to-RLOC lookups for any destination in the global routing system. 6. For backward-compatibility with non-LISP-speakers, some set of LTAs can advertise their aggregated EID-to-RLOC mappings into into the existing global routing table. This will draw traffic for those mappings to those LTAs, which serve as "LISP proxies" for non-LISP-capable devices. 7. When an ITR receives a packet for which it has no EID-to-RLOC mapping, it forwards that packet according to the aggregated information it received over its LTA connections. Note that as an implementation detail, this information, along with its cached EID-to-RLOC mappings, can simply be stored in the ITR's FIB, perhaps with some special marking to indicate "EID-to-RLOC mapping" rather than "RLOC forwarding entry". The packet is forwarded through the LTA/overlay topology until it reaches the ETR that originally advertised it; that ETR both forwards the packet to the end system and sends back a specific, cachable EID-to-RLOC mapping to the ITR which received the original packet and encpsulated it in LISP. A few things to note: - This approach does posit the creation of a new, hierarchical LTA infrastructure which will have associated capital and ongoing operational costs. Who would build that infrastructure and how they would recover those costs would depend on where its root achor points are located. Fortunately, there are existing organizations (with existing cost-recovery mechanisms) in place for those achors: IANA and the RIRs, the major global exchange points, etc. - The exact mechanism for data exchange between and throughout the LTA infrastructure is an area that needs a lot more thought, experimentation, etc. One could imagine a number of different approaches: BGP with separate AFI/SAFI (mentioned above), something DNS-like or using DNS protocols (think about zone transfer for "push" and DNS queries for "pull"), DHTs, et alia. - The LTA infrastructure, the ETR-to-LTA, and ITR-to-LTA protocol exchanges are the points at which authentication of the EID-to-RLOC database would most naturally be performed. Adding machinery at those points could address some of the open issues with LISP security. All of this is only partially thought-out at this point (not even half-baked enough to send to the RAM list) and obviously needs more work, perhaps as a successor to the LISP draft that describes the specifics of LISP 1.5. Comments? Thoughts? --Vince _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 21 12:53: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 1I1Ptt-00076V-MF; Thu, 21 Jun 2007 12:52:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Pts-00076K-G8 for ram@iab.org; Thu, 21 Jun 2007 12:52:52 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Ptn-0004PW-Kh for ram@iab.org; Thu, 21 Jun 2007 12:52:52 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 5262D59DEB; Fri, 22 Jun 2007 02:52:43 +1000 (EST) Message-ID: <467AACD1.10908@firstpr.com.au> Date: Fri, 22 Jun 2007 02:52:33 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Ivip (was ViP ...) References: <001201c7b178$5c2e0460$bc92f385@nictkafle> <467658F6.8020007@firstpr.com.au> In-Reply-To: <467658F6.8020007@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4f41a758283586c0aa45e30a4caea1da X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here is some more discussion of the similarities and differences between Ivip-mobile and various types of Mobile-IP. This is from an off-list exchange with a list member who does not at present have time to be fully involved with the discussion, and who gave me permission to post this to the list. He provides links to I-Ds concerning new developments in Mobile-IP. At the end, I also speculate that something like LISP/Ivip will either be required in order for IPv6 to be widely adopted (if no PI space is made available for AS-end-users) or if it does become widely adopted (after PI space is made available to AS-end-users). In either case, I speculate that LISP/Ivip or similar with its global network of ITRs beaming packets to whichever ETR or TTR (or some other term for the tunnel router which has a 2-way tunnel to mobile devices) would make mobile IP very much easier and probably make SHIM6 less important. - Robin http://www.firstpr.com.au/ip/ivip/ RW> Ivip's notion of large numbers of public ITRs and TTRs (by RW> paid-for access I guess) with the mobile host choosing RW> which TTR to use at any time, does not seem to have a RW> parallel in these pre-existing mobile systems, which RW> assume a fixed home-agent router. > > > > That's not 100% correct: The Mobile IPv6 bootstrapping > extensions (draft-ietf-mip6-bootstrapping-split-05.txt, > draft-ietf-mip6-bootstrapping-integrated-dhc-04.txt) allow the > mobile node to choose and change the home agent and obtain a > corresponding home address dynamically. The home agent could > be located in the mobile node's current access network (i.e., > a local home agent) or anywhere else (assuming the necessary > trust relationships between Mobility Service Authorizer and > Mobility Service Provider are in place; please see above draft > for details). Mobile IPv6 bootstrapping in split scenario http://tools.ietf.org/html/draft-ietf-mip6-bootstrapping-split A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials preconfigured on the Mobile Node. The solution defined in this document solves the Mobile IPv6 bootstrapping problem (RFC4640) when the Mobile Node's mobility service is authorized by a different service provider than basic network access, and is therefore generically applicable to any bootstrapping case. MIP6-bootstrapping for the Integrated Scenario http://tools.ietf.org/html/draft-ietf-mip6-bootstrapping-integrated-dhc Mobile IPv6 bootstrapping can be categorized into two primary scenarios, the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. > Furthermore, a mobile node may have multiple home addresses > and may be registered with multiple home agents. > draft-weniger-mobopts-mip6-cnlocpriv-02 describes a > MIPv6-based scenario, where the mobile node bootstraps with > home agents close to correspondent nodes. Such home agent > would look even more similar to an ETR. MIPv6 Correspondent Node-Targeted Location Privacy and Optimized Routing http://tools.ietf.org/html/draft-weniger-mobopts-mip6-cnlocpriv This draft discusses the problem of correspondent node-targeted location privacy in Mobile IPv6 and proposes a mechanism to achieve simultaneous optimized routing and strong correspondent node-targeted location privacy. The mechanism utilizes the MIPv6 bootstrapping mechanisms and does neither require any new network entities nor changes to home agent or correspondent node implementations. > Finally, a proxy entity in the network may send registration > and act as tunnel endpoint on behalf of the mobile node. This > is specified in the Proxy Mobile IPv6 draft > (draft-ietf-netlmm-proxymip6-01.txt) and the network entity is > called Mobile Access Gateway (MAG). The MAG would be similar > to an ITR. > > With Proxy Mobile IPv6, the Mobile Node can be an unmodified > IPv4 or IPv6 host (i.e., the host has no "second" address, > since the care-of address is managed by the proxy entity). Proxy Mobile IPv6 http://tools.ietf.org/html/draft-ietf-netlmm-proxymip6 Host based IPv6 mobility is specified in Mobile IPv6 base specification [RFC3775]. In that model, the mobile node is responsible for doing the signalling to its home agent to enable session continuity as it moves between subnets. The design principle in the case of host-based mobility relies on the mobile node being in control of the mobility management. Network based mobility allows IP session continuity for a mobile node without its involvement in mobility management. This specification describes a protocol solution for network based mobility management that relies on Mobile IPv6 signalling and reuse of home agent functionality. A proxy mobility agent in the network which manages the mobility for a mobile node is the reason for referring to this protocol as Proxy Mobile IPv6. It is possible to support mobility for IPv6 nodes by extending Mobile IPv6 [RFC-3775] signaling and reusing the home agent via a proxy mobility agent in the network. This approach to supporting mobility does not require the mobile node to be involved in the signalling required for mobility management. The proxy mobility agent in the network performs the signalling and does the mobility management on behalf of the mobile node. This is a fresh I-D, April 2007, and "Proxy Mobile IPv6" is still a fairly novel term, with Google only finding 63 pages mentioning it. Previous Proxy Mobile IPv6 I-Ds are: http://tools.ietf.org/html/draft-sgundave-mip6-proxymip6 http://tools.ietf.org/html/draft-devarapalli-netlmm-pmipv6-mipv6 Diag. 1 > So a possible MIPv6-based scenario could be the following: > > MN1---(MAG1)---\ > / \ > MN2-/ \ > (HA1)----CN > / > MN3-------------/ > > (MAG2) (HA2) > > MN3 would be Mobile IPv6 mobile node and MN1,MN2 would be > Proxy Mobile IPv6 nodes. Tunnelling would happen between MAG1 > and HA1 and between MN3 and HA1. This looks quite similar to > your ivip, no? There are some similarities. I will try to point out the differences too. Ivip-basic is just LISP (or rather some simple aspects of LISP, without multiple encapsulation or messages going along with packets regarding LISP-mapping of the source address) with the ITRs automatically catching the raw packets from the "correspondent nodes" (to use mobile IP terminology for an ordinary host which is not part of the new system), no matter where they originate from, because the Ivip-mapped address space is part of one of many "master-subnets" which are advertised in BGP. With Ivip, if the raw packet, which is addressed to the Ivip-mapped address, is not caught and tunnelled by the ITR function of an internal or border router, it will soon be forwarded to ITR outside the edge network. There is a 1-way tunnel from that ITR, and from many other ITRs handling packets from other correspondent nodes, with all these tunnels converging on an ETR, which terminates the tunnel and forwards the raw packet to the destination host. In general I think the similarities between this and mobile IP are not very significant, however - I have only a cursory understanding of Mobile-IP, and what you wrote in your second email, which I have included in the quotes above, regarding proxy Mobile IPv6 is something I had never heard of, which does have some connection. Firstly, the system doesn't require any special software on the Correspondent Nodes (CN) or the host whose address is Ivip-mapped. I understand no special software is required in Mobile-IPv6 for: 1 - A CN using ordinary Mobile-IPv6 communication to the home address of the Mobile Node (MN), where the home-agent router uses Tunnel Mode. (Special software in the CN is required to use the more efficient alternative - route optimisation: direct communication with the MN at its care-of address. 2 - A MN using Proxy Mobile-IPv6. I haven't read how it is done, but I understand that the MN has only its own IP address and it (and probably other MNs) are in a direct network connection with the proxy somehow does all the mobile-specific work for the one or more MNs it serves. Secondly, LISP/Ivip is intended to be applicable for both IPv4 and IPv6 - although I have only been discussing IPv4 use of Ivip so far. Thirdly, except for Proxy Mobile IPv6, all mobile-IP systems involve the mobile host having one or more physical IP addresses (each is a "care-of" address) where it connects to the Net, and having one stable IP address by which correspondent nodes send it packets. The simplest arrangement is Mobile-IPv6 in tunnel mode where the mobile host always responds as if it has the address it has on its home network, perhaps on an office LAN, for instance. This means the mobile host always has some fancy software which implements all this, sending and receiving packets to and from a tunnel, working from one or more physical "care-of" IP addresses (each from a different wireless network etc.) but allowing some or all of the operating system and applications to work as if they had the mobile-host's home IP address. Ivip-basic and LISP do not involve the receiving host having any IP address but its own. I haven't stated this clearly before. (By "receiving host" I mean the host whose IP address is portable between ISPs, effectively mobile and able to be multihomed by selecting different ETRs via links which use different edge networks. This "receiving host" can use this same IP address when it is located in any ISP who supports it with an ETR and correct internal routing configuration, including letting the mobile host's packets go out to the Net, as long as the ITRs all tunnel packets addresses to this IP address to the correct ETR.) In LISP/Ivip, the receiving host has no tunnel establishment or end-point features. In Ivip and I think in general LISP there is no 2-way tunnel. Only 1-way tunnelling from potentially multiple ITRs to the one ETR at any one time. (I find the LISP I-D to cover so many potential configurations that it is hard to understand clearly.) I think this makes LISP or Ivip-basic very different from Mobile-IP, except in some ways Proxy Mobile IPv6. A MN with Proxy Mobile IPv6 is something like a "receiving host" (sorry about this interchangeable "node" / "host" stuff) whose IP address has been mapped by Ivip and is in an edge network, perhaps with other receiving hosts and there is a single router which performs its ETR and default gateway functions. In both cases the MN / receiving host has only one IP address and has no special software. In both cases, the overall system of Proxy Mobile IPv6 - or Ivip-basic and the local network's ability to handle outgoing packets from the ETR/default gateway - enable the MN / receiving host to be anywhere, but still retain its one IP address. With Proxy Mobile IPv6 router is called a "Mobile Access Gateway" and I would redraw your diagram like this: Diag. 2 MN1---(MAG1)==== / = MN2-/ = (HA1)----CN = MN3============== (MAG2) (HA2) > MN3 would be Mobile IPv6 mobile node and MN1,MN2 would be > Proxy Mobile IPv6 nodes. Tunnelling would happen between MAG1 > and HA1 and between MN3 and HA1. This looks quite similar to > your ivip, no? Where ----- means ordinary two way raw packets and ==== means a 2-way tunnel between the Home Agent router and either the Mobile Node (MN3) or the (MAG1) which I understand behaves like one or more Mobile Nodes as far as the Home Agent is concerned. I think it is challenging to understand all the variations of mobile IP. I find SHIM6 really hard to understand, though I have not tried reading the whole of what I think is the most up-to-date documents: RFC4177 and draft-ietf-shim6-proto. I would like to fully understand all this. Ivip-mobile is an extension to Ivip-basic. The same principles could be used with LISP (2.00+) With both LISP and Ivip-basic, there is a large number of ITRs which 1-way tunnel packets addressed to a particular IP address or subnet, wherever the central system directs them to. The tunnelled packets for any given LISP/Ivip-mapped IP address are are all directed to a particular BGP-mapped IP address, which is the ETR. Ivip-mobile is simply: 1 - A mobile host (or some other system looking after its interests) being able to tell the database to have the ITRs tunnel the packets to any ETR, where the ETR is actually a TTR which has a two-way tunnel to the mobile host, previously established by the mobile host. As with Mobile IP's Home Agent, the TTR is the exit point for the mobile host's outgoing packets. (The TTR may also perform an ITR function on those outgoing packets if they are addressed to an Ivip-mapped address, or simply tunnel the packets to a second mobile host it has a tunnel to, if the destination of the packets is the second mobile host's Ivip-mapped IP address.) 2 - The ability of the mobile host to build tunnels to multiple TTRs and by some means have the ITRs direct packets to one or another of the TTRs. In your diagram: > MN1---(MAG1)---\ > / \ > MN2-/ \ > (HA1)----CN > / > MN3-------------/ > > (MAG2) (HA2) the hosts/nodes whose IP address is handled by the mobility system are on the left, where in my diagrams in previous messages they were on the right. Here is your diagram rewritten to match Ivip-basic: Diag. 3 /---CN1 / RN1---(ETR1)~~(TR)~~~~~(ITR1)---CN2 - ~ RN2-- ~ (ITR2)--------CN3 ~ RN3--(ETR2)~~~~~~~ (ETR3) (ITR3) .... .... (ETRn) (ITRn) TR is an ordinary transit router. ITR1 might also be a border or transit router. ITR2 is also transit router. ---- Raw packets flowing right-to-left. ~~~~ 1-way tunnelled (IP-in-IP) packets flowing generally right-to-left, except for the tunnel (ETR1)>(TR)>(ITR2)>(ETR2) which involves a little left-to-right in this diagram. In this case, ITR2 is acting like an ordinary transit router for those encapsulated packets. The ETR functions are performed in internal or border routers. Many other routers are not shown. If we add another ---- link from RN2 to ETR2 then RN2 will be multihomed. RN1, RN2 and RN3 each have a single IP address, which is within one of the "master-subnets" which all the ITRs advertise. They have no other IP address. Raw packets addressed to RN1, RN2 or RN3 from CN1, CN2 or CN3 are all forwarded to the nearest ITR. This ITR function may be performed in a router inside their edge edge network, in a border router, in a transit router or in a specialised ITR which has a stub connection to a transit router. Diag. 4 (ITR4) ~ | ~ | RN4---<-(ETR4)~~~(TR)--<--CN4 Here a packet addressed to an Ivip-mapped IP address travels from CN4 to a transit router. The transit router sends it to the ITR4 which is the closest of potentially tens of thousands of ITRs which advertise the complete set of "master-subnets" of addresses which are handled by the Ivip system. The ITR4 has only one connection - to the transit router. It encapsulates the packets in IP-in-IP headers addressed to whichever ETR the original packet's address is mapped to, according to the central database which the ETR has an up-to-date copy of, or which it queries and maintains a partial cache of. The transit router then forwards it through various other routers not shown to wherever in the world the ETR is. The ETR strips off the header and sends the raw packet on a local network to the Receiving Node. The ETR can be a relatively dumb, unmanaged, router which is not at all part of the database-ITR system. It simply decapsulates the packet and the local routing system of the edge network must be configured to forward the packet to the RNn. The ETR function is always implemented in an internal or border router. It is never in the "core" - meaning implemented in a transit router. This is because the decapsulated packets have the final IP address and need to be handled by a suitably configured local routing system to get them to the RN. Without this special routing, they would be forwarded to the border router, since they are part of one of the "master-subnets" which all the ITRs advertise. (With LISP, the mapped address is not part of any BGP advertised prefix, but the local network still needs to route the decapsulated packets to the RN, and allow packets from the RN to be forwarded out of the border router and then be forwarded by the normal BGP system.) (It is also possible for the CN to perform the ITR function and encapsulate its own outgoing packets, but that will make a mess if it is behind a NAT.) It is also possible for the RN to perform its own ETR functions. In that case, it needs a second physical, local, IP address in order that it can behave like its own ETR. In mobile-IP that IP address would be called a "care-of" address, which was reachable via an ordinary BGP-advertised prefix. In some ways, this would resemble mobile-IP, because the RN itself is taking part in tunnelling. However, for LISP or Ivip-basic, there is no 2-way tunnel, and the edge network needs to be able to get the packets sent by the RN out through the border router, for each RN to be able to send packets back to the CN. To the extent that this resembles mobile-IP, the ITRs would be like the home-agent, except that there are thousands of them, all potentially sending packets to the RN, as if it was an ETR. But the resemblance with Mobile IP is slight, since the RN needs support from the edge network to get its outgoing packets forwarded, which means the edge network needs to know about and approve of its LISP/Ivip-mapped IP address. That is why I called it a Receiving Node - because LISP (as I understand it) or Ivip-basic is a strictly one-way system. Right-to-left in the above diagram. It is up to the edge network and the normal BGP network to support the carriage of packets from the RNs to the CNs. If one of the CNs also had a LISP/Ivip-mapped address, this would involve ITRs and ETRs in the reverse direction, But these would generally be different ITRs, close to or within the edge network depicted at the left of the diagram, and would certainly be different ETRs than those depicted above, assuming the RNs and the CNs were in different edge networks. The diagram above does not depict packet flows left-to-right, because they flow by ordinary BGP methods. Now I will convert Diag. 3 to depict multiple Mobile Nodes, using an Ivip-mobile extension: the ETRs are now TTRs with a 2-way tunnel to the MN. Diag. 5 /---CN1 / MN1===(TTR1)~~(TR)~~~~~(ITR1)---CN2 = ~ MN2== ~ (ITR2)--------CN3 ~ MN3==(TTR2)~~~~~~~ (TTR3) (ITR3) .... .... (TTRn) (ITRn) ---- Raw packets flowing right-to-left. ~~~~ 1-way tunnelled (IP-in-IP) packets as described in the previous diagram. ==== 2-way tunnelled packets. The TTR (ETR) functions could be located in transit routers, border routers or internal routers. With Ivip-basic, the ETR function can't be in a transit router - it must be inside or at the border router of an edge network. A TTR function in a transit router can be tunnelled to by any MN, no matter where it is, including behind a NAT. Ideally, each MN would pick a TTR nearby, perhaps in its own edge network. In that case, the TTR somewhat resembles a MAG of Proxy Mobile IPv6. However, with this idea of Ivip-mobile, the TTRs always communicate with their MNs via two-way tunnels. The main idea is that the TTRs can be outside edge networks, but the MN will be able to find one far from whatever edge network(s) it is currently connecting to the Net with. This way, the MN can make two tunnels, via two separate radio links of two separate edge networks, to two TTRs which may be in those edge networks, at their border routers or outside the borders, but not far away. Then, it has true multihomed mobility, and it (or some other central monitoring system) can direct the ITR system to send its packets to whichever of the TTRs works best at that moment. If there was a link from MN2 to TTR2, then MN2 would be multihomed. It would have two "care-of" addresses, one from each of the edge networks it is connected to. (I assume two edge networks, such as two wireless networks, but it could still have two tunnels to two TTRs from one "care-of" address in one edge network.) The only three changes from Diag. 3 to Diag. 5 are: 1 - I haven't shown the ordinary ETRs used for Ivip-basic - but they still exist. By the way, the Ivip database and its ITRs don't need to know, or care, whether they are tunnelling packets to an ordinary ETR or to a TTR. This part of the diagram - the ITR side - hasn't changed in Diag 5 because it *is* "Ivip-basic". 2 - The MRs establish 2-way tunnels with their chosen TTRs. 3 - Packets flowing left to right from the MNs to the CNs first flow in the 2-way tunnel to a TTR. Then the TTR uses the ordinary BGP routing system to get them to the CN destination. We could make TTR2 into an ETR2 and have a link from MN2 to ETR2. Diag. 6 /---CN1 / MN1===(TTR1)~~(TR)~~~~~(ITR1)---CN2 = ~ = ~ MN2~ ~ ~ (ITR2)--------CN3 ~ ~ MN3--(ETR2)~~~~~~~ Then MN3's link to the Net would be an ordinary 1-way LISP/Ivip arrangement, via ETR2. MN2 would have an edge-network-supplied "care-of" address, from which it would establish a 2-way tunnel to TTR-1. If the ITRs tunnelled packets with MN2's Ivip-mapped address to TTR-1, MN2's connection to the Net would be Ivip-basic to TTR1 and then Ivip-mobile to itself. TTR1 would probably receive its outgoing packets and forward them via ordinary BPG. Alternatively, since MN2 is in an edge network with an ETR (ETR2), and has chosen to use this as an optional link to the Net, presumably this edge network has also allowed packets sent from MN2's LISP-Ivip-mapped address to be forwarded to the border router and handled by the normal BGP system. In that case, MN2's outgoing packets might flow via that edge network's routers, which are not shown in the diagram. If the ITRs tunnelled packet's addressed to MN2's packets to TTR-1, its connection to the Net would be ordinary Ivip-basic via ETR2. There are some similarities between the Ivip-mobile link, and mobile-IP. However, it might be best to think of Ivip-basic and its extension Ivip-mobile being like: 1 - The MN establishes one or more 2-way tunnel-mode links to TTRs, each of which is somewhat like a home-agent. However, the MN can choose between a bunch of these TTRs. Some may be in the edge network, or be its border routers. Some may be in the core. TTRs are ideally all over the world. They could be run by multiple companies with paid-for, authenticated, access. These one or more systems of TTRs, like the ETRs, do not need to have any relationship with the LISP/Ivip system (the database and the ITRs it controls). 2 - The MN's portable address has nothing to do with the addresses or physical/topological addresses of the TTRs. 3 - All packets sent by any number of correspondent nodes to the MN's Ivip-mapped (portable = mobile) address are funnelled by BGP anycast into any of the thousands or hundreds of thousands of ITRs all over the Net. (ITRs may be inside CN's edge networks, at the border or in the core. Also, the CN can perform the ITR function if it is not behind NAT.) 4 - A central database controls which ETR or TTR receives the tunnelled packets which were addressed to the CN's Ivip-mapped (portable = mobile) address. 5 - There is no need for any special software in the CN or any changes in their edge networks. (LISP requires ITRs in CN's edge networks.) 6 - Total path lengths will be optimal or close to optimal assuming there are well-placed ITRs and the MN chooses a nearby TTR. So there's no need for triangle routing, route optimisation, establishing trust between the CN and the MN etc. as is needed to optimise the path length taken by packets with mobile-IPv6. 7 - The TTR or ETR functions don't need to be coordinated by the Ivip system itself. The Ivip system is the ITRs and the database which controls their behavior. Because the explosion of the BGP routing table size is threatening to cause excessive costs for everyone (and more revenues for router manufacturers) to the tune of billions of dollars, someone like me on the RAM or RRG list who is trying to avert this can easily invoke a global network of ITRs and a central database to control them. If anyone had suggested such a thing be built just for the benefit of mobile-IP users, the proposal would have been ignored. Because we are desperate, this global network of ITRs seems like the best (probably the only) way of averting either massive router replacement and bloat, or major malfunction in the Internet. (I assume that it is impossible to institute a change in Internet protocols, and therefore all routers, host operating systems and probably application software.) Ivip is just like LISP (or at least the more straightforward aspects of LISP 2.00+ which I understand), except the ITRs can be in the core, to serve end-users of networks who don't yet have their own ITRs. This makes Ivip incrementally deployable, while I believe LISP is not. A fully functioning LISP or Ivip system is like a magic mirror system, somewhat like the banks of steerable solar mirrors: http://www.nrel.gov/data/pix/Jpegs/00036.jpg except that each IP address can be mapped to a different ETR, and the mapping can be changed rapidly without upsetting the BPG system at all. This enables ordinary hosts to have their packets sent to whichever MAG or Home-Agent a mobile-IP host desires. The principles of LISP or Ivip apply equally to IPv4 and IPv6, although there would probably be some significant differences in implementation. Since no-one thinks BGP can be replaced or vastly improved, something like LISP or Ivip is needed in the next few years. Either LISP or Ivip makes it so much more simple and efficient to do mobile-IP. If IPv6 ever becomes widely adopted, perhaps something like LISP or Ivip needs to be implemented for IPv6 too. This could happen if RIRs start handing out PI address space to AS-end-users. Alternatively, if RIRs stick to current policy and don't hand out PI space, someone will need to create a LISP or Ivip system before ordinary networks (other than researchers, 3G mobile networks and the Chinese government) adopt IPv6 widely. Either way, I think IPv6 will have something like LISP or Ivip. This involves some special routers and a central control system, but no direct involvement with host software and no extra burden on most of the DFZ routers. I guess this would make SHIM6 largely redundant. SHIM6 is clearly not the portability and multihoming system most end-users want, so on its own, it has not been enough to make people want to adopt IPv6 without PI address space. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 22 03:38: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 1I1diL-0003gK-Lm; Fri, 22 Jun 2007 03:37:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1diK-0003gE-Ad for ram@iab.org; Fri, 22 Jun 2007 03:37:52 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1diJ-0000Nf-1q for ram@iab.org; Fri, 22 Jun 2007 03:37:52 -0400 Received: by ug-out-1314.google.com with SMTP id m2so791492uge for ; Fri, 22 Jun 2007 00:37:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=o7KNwsdvhnI1xxHpowGg7h0oX38zzoCPR3tV0MTySj8FmVzwjCTOyUIRZZ6rLMmUOdI608mLWyMHM/Jv9zkHKNr6Udb4e1onJpLC8YabAOmxqTie1avZ2MM1oymgsXpIPf4U9eommf8bUhouNE5zxbreodyaZ/k4OUaTVoiM7SQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=CwkRqp2hHeALJhQTw3zy8Fr5leHa3QYLpL0zY9/qgLWRWQXdV6l+geDAhHQJ/Z09Pq41ZQpL23eHJ9wOey3j9Zf1ATswi4RQOtH8TIlqD8aviIs93eqDBsBT3pdbjwsMLn64yavx1dv0GeClMMT5ot/azXf0HuDMHCWAglF0+d0= Received: by 10.82.175.17 with SMTP id x17mr5755097bue.1182497870238; Fri, 22 Jun 2007 00:37:50 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id f4sm9521527nfh.2007.06.22.00.37.48 (version=SSLv3 cipher=RC4-MD5); Fri, 22 Jun 2007 00:37:49 -0700 (PDT) Message-ID: <467B7C4B.6030706@gmail.com> Date: Fri, 22 Jun 2007 09:37:47 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Robin Whittle Subject: Re: [RAM] Ivip (was ViP ...) References: <001201c7b178$5c2e0460$bc92f385@nictkafle> <467658F6.8020007@firstpr.com.au> <467AACD1.10908@firstpr.com.au> In-Reply-To: <467AACD1.10908@firstpr.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 ... > Either way, I think IPv6 will have something like LISP or Ivip. > This involves some special routers and a central control > system, but no direct involvement with host software and no > extra burden on most of the DFZ routers. > > I guess this would make SHIM6 largely redundant. > > SHIM6 is clearly not the portability and multihoming system most > end-users want, so on its own, it has not been enough to make > people want to adopt IPv6 without PI address space. I suggest we don't have that conversation. I could write a long rant in response - but it seems much more constructive to talk about routing and addressing here; shim6 is an orthogonal discussion, and I believe we should just let the WG finish its job. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 22 09:42: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 1I1jOe-0001ik-RB; Fri, 22 Jun 2007 09:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jOc-0001if-TY for ram@iab.org; Fri, 22 Jun 2007 09:41:54 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1jOa-0001hr-NF for ram@iab.org; Fri, 22 Jun 2007 09:41:54 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 57A4C872D7; Fri, 22 Jun 2007 09:41:52 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Ivip (was ViP ...) Message-Id: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> Date: Fri, 22 Jun 2007 09:41:52 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: Brian E Carpenter >> SHIM6 is clearly not the portability and multihoming system most >> end-users want, so on its own, it has not been enough to make people >> want to adopt IPv6 without PI address space. > I suggest we don't have that conversation. I could write a long rant in > response - but it seems much more constructive to talk about routing > and addressing here Indeed... > shim6 is an orthogonal discussion, and I believe we should just let the > WG finish its job. I basically agree; but he does have a point, that many (most?) of the users are not happy with the broad direction of the SHIM6 solution... which is a problem for all of us, because the technical reasons why we went that way are significant. A architectural-level discussion of why people are unhappy with SHIM6, and how that relates to those inescapable technical drivers, might not be out of place here... Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jun 23 08:05: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 1I24MT-0005t5-3A; Sat, 23 Jun 2007 08:05:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I24MS-0005t0-3B for ram@iab.org; Sat, 23 Jun 2007 08:05:04 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I24MQ-0006Z9-6v for ram@iab.org; Sat, 23 Jun 2007 08:05:04 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 2354559E3D; Sat, 23 Jun 2007 22:04:55 +1000 (EST) Message-ID: <467D0C5C.6080004@firstpr.com.au> Date: Sat, 23 Jun 2007 22:04:44 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Ivip (was ViP ...) References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> In-Reply-To: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Brian Carpenter , Noel Chiappa X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 wasn't suggesting any change to SHIM6's development. What I wrote: >>> SHIM6 is clearly not the portability and multihoming system most >>> end-users want, so on its own, it has not been enough to make people >>> want to adopt IPv6 without PI address space. seems to be factual. Noel wrote: > A architectural-level discussion of why people are unhappy > with SHIM6, and how that relates to those inescapable > technical drivers, might not be out of place here... I agree. I think a global system for LISP, Ivip or similar will be built. I think this system will provide good portability and hopefully TE for ordinary hosts - IPv4 or IPv6 - without additions to the protocol stack or changes to operating systems. I think this has to happen soon for IPv4, because the BGP system can't be expected to keep up with the growth in the number of advertised prefixes. We have to find a way to provide portability, multihoming, TE and ideally great mobility for millions of end-users, without altering hosts. SHIM6 would still work with any such LISP or Ivip system for IPv6 - so it is "orthogonal" to any such system. However the things which SHIM6 would provide would already be largely or entirely available via the LISP/Ivip system. I understand that SHIM6 is basically a host-oriented system, operating on a single IP address at a time, with the control necessarily being exercised within the multihomed host itself. I may be wrong - it is complex and I haven't properly read draft-ietf-shim6-proto. LISP/Ivip, as I envisage it working, can handle individual IP addresses or arbitrary sets of addresses with equal ease, and does not require any new software or for the host(s) whose addresses are being managed to be in any way aware of it. Nonetheless, a single host could manage its own LISP/Ivip mapping, or some centralised system could perform this task for it, for instance to choose the best ETR in a multihoming setting when one link fails. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jun 23 08: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 1I24NK-0006Y9-FN; Sat, 23 Jun 2007 08:05:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I24NJ-0006Y3-Ro for ram@iab.org; Sat, 23 Jun 2007 08:05:57 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I24NH-0006lu-Ok for ram@iab.org; Sat, 23 Jun 2007 08:05:57 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 5DDC259E3D; Sat, 23 Jun 2007 22:05:54 +1000 (EST) Message-ID: <467D0C97.4050609@firstpr.com.au> Date: Sat, 23 Jun 2007 22:05:43 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org References: <001201c7b178$5c2e0460$bc92f385@nictkafle> <467658F6.8020007@firstpr.com.au> <467AACD1.10908@firstpr.com.au> In-Reply-To: <467AACD1.10908@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Subject: [RAM] Re: Ivip (was ViP ...) diagram X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here is a diagram which might help with understanding Ivip. I am maintaining a list of the longer messages I write about Ivip at: http://www.firstpr.com.au/ip/ivip/ At present, this is the rambling Ivip documentation. I plan to write a much more readable Internet Draft in August. Dino wrote over a week ago that Ivip was like LISP 1.5. I have tried to understand LISP 1.5 but have not been successful. I hope he or Vince can explain it better to me, or ideally to the list. I imagine many people have difficulty imagining concrete examples of the LISP variants, because the descriptions in the I-D are rather conceptual. What I have written about LISP is just my understanding - and doesn't include a bunch of LISP stuff such as ICMP messages, multiple encapsulation etc. I assume that both LISP and Ivip ITRs can have either a full "push" copy of the central database or use "pull" and caching. Here are four Edge Networks. ........ .................. . . Edge-A . . Edge-B . . H01 . . H04 IH01 . . H02 . . H05 IH02 BR1 . H03 . ETR1 H06 IH03 . TR1 TR2 . ETR2 ........ .................. ITR1 TR3 TR4 ITR2 ............. .................. . . H10 IH07 ITR4 . ETR3 H07 IH04 ETR4 TR5 BR2 H11 IH08 . . ITR3 H08 IH05 . . H12 IH09 . . H09 IH06 . . . . Edge-D . . Edge-C .............. ................... Key: TRx Transit routers BRx Border routers ITRx Ingress Tunnel Routers } In this example, these are also ETRx Egress Tunnel Routers } function as internal or BGP } routers. ETRs have at least one IP address which is a normal, BGP-reachable, IP address. Hxx Hosts with ordinary BGP-routable IP addresses, either PI or PA. For instance desktop machines and servers. IHxx Hosts with one or more IP addresses which are mapped by the LISP/Ivip system. These could be routers too. See my earlier messages for how each such IP address is within one of the "master-subnets" which all the ITRs advertise. With LISP 2+, hosts in Edge-A can't send packets to any of the IHxx hosts with LISP-mapped addresses, because those addresses are not part of prefixes advertised in BGP. I think such versions of LISP cannot be successfully deployed for this reason - since no-one would want an IP address which some hosts couldn't send packets to. With Ivip, the mapped addresses are part of a BGP-advertised prefix, so packets from Edge-A sent to such IP addresses are forwarded to the nearest ITR, since all ITRs anycast advertise the prefixes ("master-subnets") which Ivip maps. There are five BGP advertised prefixes in this example. One for each edge network and one for the Ivip system - though in reality the Ivip system would probably handle many prefixes. The diagram shows 4 groups of normal hosts H0 to H12, each of which uses PA addresses from its edge network. The 9 hosts with Ivip-mapped addresses can each use their one or more Ivip-mapped addresses provided they are in an edge network with an ETR and that edge network's routing system firstly forwards the decapsulated packets to the host and secondly allows packets from that host's IP address to be forwarded normally: to any internal host or out via the border router to ordinary BGP routers. Here are descriptions of the networks, with the BGP prefixes each one advertises. Edge-A 11.0.0.0/16 ------ An ordinary ISP or AS-end-user network with no special router functions to support LISP or Ivip. The hosts in this network are all ordinary hosts with conventional IP addresses which can be reached from anywhere via the current BGP system. For this example, I assume these hosts have addresses provided by Edge-A - PA (Provider Assigned) addresses. So there is no portability between ISPs (different edge networks) for the IP addresses used by these hosts. It would also be possible for one or more hosts to be run by some organisation with an ASN, in which case that AS-end-user can allow Edge-A to advertise one of its PI (Provider Independent) subnets at its border router and the hosts can use that address space. The primary purpose of LISP/Ivip is to allow portability and multihoming to such end-users without them needing to become Autonomous Systems or to have PI space assigned to them. Unless Ivip-mobile is used (which I have described in several recent messages and which I will mention briefly below), the hosts in this edge network cannot use LISP/Ivip-mapped addresses. They can however send packets to and from with all the IHxx hosts in other edge networks - which have Ivip-mapped addresses - by using one of the "core-ITRs", probably ITR1 which is closest. Edge-B 12.0.0.0/16 ------ This network has been upgraded so its border router also performs ETR functions. The internal routing system has also been configured to handle whatever the IP addresses are of three hosts IH01, IH02 and IH03 which have LISP/Ivip-mapped IP addresses. A second ETR2 function is implemented on an internal router. Because there is no ITR in Edge-B, all its hosts rely on a "core-ITR" when sending packets to any LISP/Ivip-mapped address outside Edge-B. Edge-C 14.0.0.0/16 ------ Like Edge-B and Edge-D, this has a bunch of ordinary hosts and IHxx hosts with LISP/Ivip-mapped addresses. Any edge network with IHxx hosts needs at least one ETR. This can be at the border router or at an internal router. Edge-C has it in an internal router. Edge-C has an ITR, also as in internal router. These ITR and ETR functions are assumed to be additional to the ordinary internal router functions. However they could be performed by a specialised router or server which only does this function, and has a single link to an internal or border router. Also, the ITR and ETR functions could be performed by the same router or server. Edge-D 15.0.0.0/16 ------ This has IHxx hosts too, and its single border router performs both ITR and ETR functions. Hosts don't need to know where ITRs are - Ivip-mapped packets are naturally forwarded to them. Whoever runs each Ivip-mapped host does need to know the IP address of the one or more ETRs in the edge network which can decapsulate packets for it. However, the host itself does not need any configuration. There could be further ITRs and ETRs inside as well. Note that all these IHxx hosts only have the IP address which is LISP/Ivip-mapped to them. This is not like most mobile-IP scenarios (all scenarios except Proxy Mobile IPv6?) where the host has a care-of address and some special software to create a tunnel to a home agent or some other device, where that tunnel carries packets to and from the IP address the host keeps when it moves from one edge network to another. I suppose a host could have one or more of both kinds of IP address. None of these hosts requires any special software. All this applies to both IPv4 and IPv6, but I will use IPv4 example addresses. I will assume a single Ivip system, but there could be multiple such systems operating side-by-side, without any problems. Each would have its own database and set of ITRs, but they could all tunnel packets to the same ETRs in edge networks all over the world, which require no coordination. A Master-Subnet and the mapping ------------------------------- There are likely to be multiple "master-subnets" handled by the Ivip - maybe hundreds or a few thousand. Ideally they would be larger subnets. As more and more address space is Ivip-mapped, the previously isolated subnets would tend to adjoin each other, so less BGP advertisements would be required. Let's say the Ford Motor Company, which (as far as I know) is currently assigned 19.0.0.0/8 but which does not advertise it (and therefore doesn't use it publicly), decides to give control of this of the Ivip system. That is 16,777,216 IP addresses. Assuming the Ivip system doesn't also work with neighbouring /8s, the Ivip system considers this as one of its "master-subnets". Every ITR advertises this subnet (anycast) and all the other "master subnets". Here I give some example mappings for two tiny sections of this large master-subnet. IP address Host this Current mapping: the to be mapped address is IP address of an ETR mapped for 19.0.0.0 IH05 13.0.3.1 ETR3 1 2 IH06 13.0.3.1 ETR3 3 IH01 12.0.2.1 ETR1 4 IH08 14.0.8.8 ETR4 5 IH08 14.0.8.8 ETR4 6 IH08 14.0.8.8 ETR4 7 IH08 14.0.8.8 ETR4 8 IH02 12.0.2.1 ETR1 19.0.0.9 IH05 13.0.1.1 ETR3 . . . etc 19.75.0.0 1 IH03 12.0.2.1 ETR1 2 3 IH07 14.0.8.8 ETR4 4 IH04 13.0.1.1 ETR3 5 IH09 14.0.8.8 ETR4 6 IH02 12.0.7.7 ETR2 IH08 gets four contiguous IP addresses. They are on binary boundaries, but there's nothing about the Ivip system which makes this necessary. IH02 gets two IP addresses. When the database changes the mapping for a large number of IP addresses, say 1024 or so, it is generally faster and easier to communicate this in a prefix format or as a range between two addresses than to specify the change of mapping for each IP address. If an ITR uses "pull" and enquires to the central database, or some proxy server for it (perhaps a local "pull" database ITR?) about 19.0.0.5, it would receive in the reply not just the current mapping (14.0.8.8) but information indicating that the same mapping applies for adjacent addresses 19.0.0.4 to 19.0.0.7 inclusive. A multihomed host or router, not shown, could have two different links such as via ADSL and a cable modem to Edge-B and Edge-C. By changing the database entry for that host's or router's one or more IP addresses from pointing to ETR2 to make them point to ETR3, packets to the host would arrive on the Edge-C link rather than from Edge-B. Example packet flows -------------------- ---- Ordinary packets with their natural IP address. ~~~~ Packets encapsulated with an IP-in-IP header, so the outer header's destination address is that of whichever ETR the database currently specifies. Normal <---> Ivip-mapped H01->-BR1----TR1----ITR1~~~~~TR3~~~~TR2~~~~ETR1-->-IH02 H01-<-BR1----TR1--------------------TR2----ETR1--<-IH02 Left to right, the packet leaves Edge-A and is forwarded to the nearest ITR. All ITRs advertise 19.0.0.0/8. ITR1 tunnels the packet to 12.0.2.1, which is ETR1. ETR1 decapsulates it and Edge-B's routing system delivers the packet to IH02. This is a longer path than would be the case without Ivip, because the packet takes a detour to reach the nearest ITR. Ideally, there would be ITRs scattered through the core of the network. When the two edge networks are far apart, it doesn't matter much if there are only one or a few ITRs somewhere in the path. All that matters is that the packet does get to an ITR at some point. If Edge-A and Edge-B were close to each other, but the nearest ITR was a long way away, then the packets would travel on a longer path than would otherwise be necessary. With ITR functions located in transit routers, ideally they would be one hop away from border routers, so there would be little or no lengthening of the path. A better result is if the ITR function is performed by the border router, or an internal router. Then there is no longer path - only a slightly longer part of the path with the small burden of the IP-in-IP header. In the reverse direction, H01's address is an ordinary non-Ivip-mapped address so it is forwarded normally. ETR1 in this case is acting as an ordinary border router. Ivip-mapped <---> Ivip-mapped In this case, I will illustrate packet flow between edge networks which both have their own ITRs and ETRs, so there is no increase in path length for using Ivip. IH08->-ITR4~~~~~TR5~~~~~BR2~~~ETR3->-IH06 IH08-<-ETR4~~~~~TR5~~~~~BR2~~~ITR3-<-IH06 Ivip-mobile ----------- All this means is that the ETR is a "TTR" (Translating Tunnel Router). The database and ITRs don't need to know the packets are directed to a TTR. I explained Ivip-mobile in greater detail in previous messages. The Mobile Host has some kind of Internet connection which gives it a "care of" address. This is different from normal Ivip, where the host has only (or at least only needs) the Ivip-mapped address. The Mobile Host establishes a two-way tunnel of some kind, maybe IP-in-IP or some compressed, encrypted tunnel, with the TTR of its choice. Ideally this would be inside the edge network the host is currently connected to, or at its border router. However the TTR could be at any location in the Net, including inside other edge networks. All it needs is a normal IP address. The host could be behind multiple layers of NAT - as long as it can establish the tunnel. There could be multiple independent networks of TTRs each with TTRs in the core of the Internet, but ideally close to border routers. Then a host can find one which is pretty close so the packet paths generally won't be much longer than necessary. Having the TTR in the same edge network is good because there is no difference in path length in the core of the Net, and minimal increase in path length when communicating with other hosts in the same edge network. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 25 02:57: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 1I2iUw-000375-GB; Mon, 25 Jun 2007 02:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2iUu-00036w-5Q for ram@iab.org; Mon, 25 Jun 2007 02:56:28 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2iUs-0003UY-8b for ram@iab.org; Mon, 25 Jun 2007 02:56:28 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 8E25459DA1; Mon, 25 Jun 2007 16:56:18 +1000 (EST) Message-ID: <467F6708.2060400@firstpr.com.au> Date: Mon, 25 Jun 2007 16:56:08 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Preliminary thoughts on LISP 1.5 References: <20070620183547.GA24174@cisco.com> In-Reply-To: <20070620183547.GA24174@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Hi Vince, I have read your email carefully at least three times and I still don't have a clear understanding of what you are trying to describe. Can you or anyone else provide examples, with more concrete descriptions, diagrams etc. for each point? For instance, I couldn't develop a clear example in my mind of any one of your options for point 1. I recognise point 6 as being similar to what I thought distinguished my Ivip idea from LISP. As far as I knew, apart from maybe LISP 1.0 (which I understand is a conceptual stage rather than something which helps reduce the size of the BGP routing table), for all other LISP variants the (EID) addresses mapped by the system (to ETR addresses) were not within any prefix which was advertised by a BGP router. But in this message you raise the possibility of a new construct: an LTA (LISP Translation Aggregator). Point 6 mentions a (sub)set of LTAs advertising "their aggregated EID-to-RLOC mappings" to the existing global routing table. Maybe that means something like what I propose for Ivip ITRs. Dino protested on 15 June (Re: ViP: Anycast ITRs in the DFZ & mobile tunnels): > Robin, this is LISP 1.5, don't you realize that? In LISP 1.5, > when EIDs come out of PI space, they cannot be routeable via > the BGP Internet, so they use another topology that does carry > EIDs. This is exactly what you are describing above. You and probably Dino have a much more concrete idea of LISP 1.5 than I am able to create in my own mind by reading what little I have to go on. I am not convinced Dino understood correctly what I had in mind when I wrote my first piece. Hopefully, seven long Ivip messages since then will enable anyone with sufficient patience to have a clearer idea of what I am trying to communicate. I plan to write a much more accessible I-D in August. For now, links to the longer messages I wrote are at: http://www.firstpr.com.au/ip/ivip/ I got no idea from your LISP I-D: LISP 1.5: where EIDs are routable for bootstrapping EID-to-RLOC mappings; such routing is via a separate topology. that LISP 1.5 involved any router advertising prefixes containing EID addresses to the rest of the BGP system. It is five months since you released the LISP I-D and I suspect I am not the only one who is struggling to create a concrete example in their minds of LISP 1.5. Anything you can write by way of examples would really help. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 25 03:24: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 1I2ive-0004JX-9f; Mon, 25 Jun 2007 03:24:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2ivd-0004FG-Ad for ram@iab.org; Mon, 25 Jun 2007 03:24:05 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2ivb-0008Nf-Aw for ram@iab.org; Mon, 25 Jun 2007 03:24:05 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id B8FF759DA1; Mon, 25 Jun 2007 17:24:01 +1000 (EST) Message-ID: <467F6D87.2050603@firstpr.com.au> Date: Mon, 25 Jun 2007 17:23:51 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [RAM] RRG & ITR lists: BGP path hunting, stability, MRAI timer, CPU and memory load etc. X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 the limitations of the BGP routing system are the primary constraint forcing us to consider heroic initiatives such as LISP, Ivip or whatever, I think many RAM list people might be interested in some discussions concerning: BGP's MRAI timer and how it was specified in RFC1771 to allow withdrawals to pass, how this was largely ignored by router vendors by about 2002, and how in RFC4271 the MRAI timer was prohibited from allowing withdrawals to pass: the default timer applies to all announcements about a prefix, including withdrawals. My examples of how this leads to patterns of behavior by small sections of the BGP system which become "amplified" by other sections. (Think "reverberated".) A single little network of four routers, with modern (non-RFC1771-compliant) MRAI timer functions, can turn a broken link or some other withdrawal event into: 1 - An announcement of a longer best path. 2 - About 30 seconds later, the withdrawal of that prefix. It is easy to create a topology which produces multiple such announcements at ~30 second spacings, followed by the withdrawal 30 seconds after the last best path announcement. The exact timings and behavior would be more varied than my hand-worked examples, but the basic pattern is clearly part of the "path hunting" problem, as Geoff Huston's research indicates. Tony Li's and now Geoff Huston's ID on Improving BGP stability, which includes a "Path Length Damping" function which would replace the current MRAI timer with something (I think) not unlike what was specified back in 1995 by RFC1771. Version 01 of 13 June is at: http://tools.ietf.org/html/draft-li-bgp-stability Questions about how different trends in the topology of the Internet affect the load on BGP routers. Actual capacity of routers to handle large numbers of routes including splitting the load amongst multiple router processors. (Robert Raszuk, IDR message 2428.) Flap damping and how it might have been much better. Processor and RAM speeds, RAM capacities etc. In the RRG archives, the starts of the threads are: Geoff Huston's article on BGP stability, update statistics and damping http://psg.com/lists/rrg/2007/msg00138.html (2007-06-19) BGP path hunting, MRAI timer and Path Length Damping http://psg.com/lists/rrg/2007/msg00146.html (2007-06-21) In the IDR list these threads continued. Reading messages from: http://www1.ietf.org/mail-archive/web/idr/current/msg02413.html takes in the remainder of the discussion to date. I understand the best place to discuss these things is on the IDR list, not on the RAM list. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 25 07:39: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 1I2muG-0006MC-8D; Mon, 25 Jun 2007 07:38:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2muD-0006La-EP for ram@iab.org; Mon, 25 Jun 2007 07:38:54 -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 1I2muC-0004bT-4E for ram@iab.org; Mon, 25 Jun 2007 07:38:53 -0400 Received: from 229.224.sj.icannsanjuan.pr (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l5PBJoFS021484; Mon, 25 Jun 2007 04:20:01 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by 229.224.sj.icannsanjuan.pr (PGP Universal service); Mon, 25 Jun 2007 07:38:42 -0400 X-PGP-Universal: processed; by 229.224.sj.icannsanjuan.pr on Mon, 25 Jun 2007 07:38:42 -0400 In-Reply-To: <467F6D87.2050603@firstpr.com.au> References: <467F6D87.2050603@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <0DED4317-4989-42AC-82B0-57392C118B80@virtualized.org> From: David Conrad Subject: Re: [RAM] RRG & ITR lists: BGP path hunting, stability, MRAI timer, CPU and memory load etc. Date: Mon, 25 Jun 2007 07:38:30 -0400 To: Robin Whittle 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: 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 Robin, On Jun 25, 2007, at 3:23 AM, Robin Whittle wrote: > Since the limitations of the BGP routing system are the primary > constraint forcing us to consider heroic initiatives such as > LISP, Why do you think this? I thought the problem was that flat routing is hard. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 25 11:52: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 1I2qri-0003fk-EP; Mon, 25 Jun 2007 11:52:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pvJ-0002Uc-5o for ram@iab.org; Mon, 25 Jun 2007 10:52:13 -0400 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2pvG-0002Mt-Lg for ram@iab.org; Mon, 25 Jun 2007 10:52:13 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id l5PEpsTe179094 for ; Mon, 25 Jun 2007 14:51:54 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5PEpne41933420 for ; Mon, 25 Jun 2007 16:51:54 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5PEpnWD004848 for ; Mon, 25 Jun 2007 16:51:49 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5PEpmUR004817; Mon, 25 Jun 2007 16:51:48 +0200 Received: from [9.4.210.3] ([9.4.210.3]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA508766; Mon, 25 Jun 2007 16:51:37 +0200 Message-ID: <467FCF66.6090207@zurich.ibm.com> Date: Mon, 25 Jun 2007 16:21:26 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Robin Whittle Subject: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> In-Reply-To: <467D0C5C.6080004@firstpr.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-Mailman-Approved-At: Mon, 25 Jun 2007 11:52:34 -0400 Cc: 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 2007-06-23 14:04, Robin Whittle wrote: > I wasn't suggesting any change to SHIM6's development. What I > wrote: > >>>> SHIM6 is clearly not the portability and multihoming system most >>>> end-users want, so on its own, it has not been enough to make people >>>> want to adopt IPv6 without PI address space. > > seems to be factual. No. If shim6 was shipping code in the popular operating systems, we could start the clock on that evaluation. Since it isn't, it's way too soon to say anything. > > Noel wrote: > >> A architectural-level discussion of why people are unhappy >> with SHIM6, and how that relates to those inescapable >> technical drivers, might not be out of place here... > > I agree. First of all, please identify those people. The ones who were identified in last year's round of meetings with IAB members have been heard from, and their main issue - lack of ISP control over multihoming policy - has certainly been heard. As far as I understand the history of these discussions, we're here to look for another solution that has that property, which would certainly move the control point for locator selection out from the host towards the border router or beyond. > I think a global system for LISP, Ivip or similar will be built. > I think this system will provide good portability I'm not sure exactly what you mean by portability. > and hopefully > TE for ordinary hosts - IPv4 or IPv6 - Hosts aren't interested in TE. That is an enterprise network operator, or ISP interest. > without additions to the > protocol stack or changes to operating systems. You should know that one of the reasons we took a host based approach in developing shim6 was because we saw no sign of a proposal to solve the problem in the routing system. So, now we have a near-ready host based solution. Why can't we just let it become ready and see if it works? Why let shim6 be a distraction here? > I think this > has to happen soon for IPv4, because the BGP system can't be > expected to keep up with the growth in the number of advertised > prefixes. We have to find a way to provide portability, > multihoming, TE and ideally great mobility for millions of > end-users, without altering hosts. > > SHIM6 would still work with any such LISP or Ivip system for > IPv6 - so it is "orthogonal" to any such system. However the > things which SHIM6 would provide would already be largely or > entirely available via the LISP/Ivip system. So what? The approaches are orthogonal, as you say. > > I understand that SHIM6 is basically a host-oriented system, > operating on a single IP address at a time, It operates on a locator set. > with the control > necessarily being exercised within the multihomed host itself. Final choice is made in the shim. There's no reason the policy that determines the choice shouldn't be distributed site-wide - that's why RFC 3484 is relevant. And there is a draft on a shim6 proxy, but that raises some standard stateful-proxy issues. > I may be wrong - it is complex and I haven't properly read > draft-ietf-shim6-proto. > > LISP/Ivip, as I envisage it working, can handle individual IP > addresses or arbitrary sets of addresses with equal ease, I think NERD only scales if it handles prefixes, not /128s or /32s. > and > does not require any new software or for the host(s) whose > addresses are being managed to be in any way aware of it. > Nonetheless, a single host could manage its own LISP/Ivip > mapping, or some centralised system could perform this task for > it, for instance to choose the best ETR in a multihoming setting > when one link fails. Yes, that might be a way for users to take control back from ISPs, although I think shim6 will prove an easier way to do that. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 25 13:44: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 1I2scA-0005yL-Mg; Mon, 25 Jun 2007 13:44:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sc9-0005yG-Ho for ram@iab.org; Mon, 25 Jun 2007 13:44:37 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2sc8-0005K2-8Z for ram@iab.org; Mon, 25 Jun 2007 13:44:37 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Jun 2007 19:43:56 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAL+bf0aQ/uCLh2dsb2JhbACBSY1VAQEJDiw X-IronPort-AV: i="4.16,460,1175464800"; d="scan'208"; a="146462619:sNHT2106396692" 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 l5PHhtSr019639; Mon, 25 Jun 2007 19:43:55 +0200 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp263.cisco.com [10.61.65.7]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5PHhoTC013825; Mon, 25 Jun 2007 17:43:50 GMT Message-ID: <467FFECE.5090005@cisco.com> Date: Mon, 25 Jun 2007 19:43:42 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> In-Reply-To: <467FCF66.6090207@zurich.ibm.com> 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=112; t=1182793435; x=1183657435; 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=20OK, =20shim6, =20if=20we=20must=20[Re=3A=20[RAM]=20Ivip =20(was=20ViP=20...)] |Sender:=20; bh=LPfd+4V6JZPEHcY/hLBJ/6oybbLpKDkQYsnDsBBDcb0=; b=Ljqvl6b1Bg6os7aARwawVzoMqzpapN3jF7ylR+ol50ayQMLLEW+ufzuehuRww/TIeu8Am1In QS4SDLt6eJTvwH+7dLK0CEN4HvTg3qJGVrQU7vv5Nq+UIQ0C/WAs2uvA; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: ram@iab.org, Robin Whittle , Noel Chiappa X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Brian E Carpenter wrote: > I think NERD only scales if it handles prefixes, not /128s > or /32s. I agree. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 25 21:52: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 1I30Dz-0003hp-GW; Mon, 25 Jun 2007 21:52:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I30Dy-0003hc-8R for ram@iab.org; Mon, 25 Jun 2007 21:52:10 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I30Dv-0002pm-PE for ram@iab.org; Mon, 25 Jun 2007 21:52:10 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id EC3C459DA1; Tue, 26 Jun 2007 11:52:02 +1000 (EST) Message-ID: <46807138.6090705@firstpr.com.au> Date: Tue, 26 Jun 2007 11:51:52 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> In-Reply-To: <467FCF66.6090207@zurich.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: Brian E Carpenter , Noel Chiappa X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Brian Carpenter wrote, in part: > No. If shim6 was shipping code in the popular operating systems, we could > start the clock on that evaluation. Since it isn't, it's way too soon > to say anything. I think it is fair enough to say that if an AS-end-user or an ISP has a prefix of IP addresses with a bunch of hosts on these addresses (especially hosts belonging to another organisation) and they want to multihome that prefix, then they would much prefer to do the whole thing with a router and some robust, global, system such as LISP, Ivip or whatever - rather than have to configure a bunch of disparate host devices, operating systems etc. to all respond to some centralised control system so each SHIM6 system behaved as required. There is the practical problem of either the ISP or the owner of all the hosts (and there may be thousands of separate owners, many of them not very technically adept) making sure they are all configured correctly. For instance after re-installing an operating system, plugging in a new machine etc. Testing the SHIM6 system is properly controlled from the single point could be tricky too. This is all labour-intensive, full of administrative hassles across organisational boundaries and subject to technical error. Then what if the central control point has to change? All the hundreds or thousands of hosts need to be reconfigured. Customers who own the hosts don't want an ISP administrator poking around their system, for security reasons. So the ISP has to give them explicit instructions on exactly how to configure their machine - but there could be many operating systems, different versions of the operating systems, many different "appliance" devices and so many different ways an IPv6 host might need to be configured, from the users' point of view. This is roughly analogous to the ISP having to provide bullet-proof instructions for people with limited technical skills on how to configure several versions of Windows and Mac operating systems to dial into their network. >> Noel wrote: >> >> RW> A architectural-level discussion of why people are unhappy >> RW> with SHIM6, and how that relates to those inescapable >> RW> technical drivers, might not be out of place here... >> >> I agree. > > First of all, please identify those people. The ones who were > identified in last year's round of meetings with IAB members have been > heard from, and their main issue - lack of ISP control over multihoming > policy - has certainly been heard. As far as I understand the history > of these discussions, we're here to look for another solution that > has that property, which would certainly move the control point for > locator selection out from the host towards the border router > or beyond. I agree that we are looking for such a solution. The only ones which seem to be available for IPv4, which make no demands such as changing operating systems are LISP or some similar or derivative system such as Ivip, which involves tunneling packets and popping them out with their raw IP addresses in a local environment where they are routed to their destination host. The hosts at both ends of the communication are blissfully unaware of how the packets have been handled in transit. Each host with an LISP/Ivip-mapped IP addresses only has that IP address. Since it seems that some form of LISP/Ivip/whatever is practical and since no-one has a better solution to the problem of the BGP routing table threatening to swamp the DFZ routers in the uncomfortably near future, I think it is reasonable to believe that something like LISP/Ivip will be built around the end of the decade. However I think we would need to make faster progress than in the last 6 months to achieve this. The quotes below are from me. >> I think a global system for LISP, Ivip or similar will be built. >> I think this system will provide good portability > > I'm not sure exactly what you mean by portability. A primary goal of Ivip - and I assume LISP - is to allow someone who has an IP address, or a prefix of addresses, to use those addresses for their host(s) which are either located at "any ISP", or which are housed in their office, factory etc. and link to the Net via a link through "any ISP". "Any ISP" is an ISP which has an ETR and local routing support for whichever LISP/Ivip-mapped addresses the customer is using at the time. The ITRs are a global system which tunnel the packets to whichever IP address the owner of these hosts chooses - because the owner of these hosts has some arrangement with the LISP/Ivip system by which they control that part of the database which controls how the ITRs tunnel incoming packets whose destination address is one of their IP addresses. I think different people in this discussion have different models of administration of IP addresses, different goals etc. for how LISP or whatever would be used. A primary goal I have is to enable a LISP/Ivip system to provide effectively portable IP addresses or prefixes to millions or in principle a billion or two end-users. This portability between ISP's ETRs - between any ETR in any edge network - is a prerequisite for multihoming. LISP or Ivip enables multihoming by having the customer site have two links to two ISPs where the ETRs of both ISPs are ready to accept encapsulated packets and to decapsulate them, and where the local routing system is ready to forward the packets to the link to the customer site. (The ISP's network also needs to accept outgoing packets and enable those which match BGP advertised prefixes out to the Net, probably via an ITR so outgoing packets to LISP/Ivip-mapped addresses don't depend on public-access ITRs outside the ISP's edge network.) Then by one means or another, the LISP/Ivip ITRs all over the world tunnel the packets to one or the other ETR - whatever is needed to keep the customer site connected when one link or one ISP goes down. >> and hopefully >> TE for ordinary hosts - IPv4 or IPv6 - > > Hosts aren't interested in TE. That is an enterprise > network operator, or ISP interest. It is probably not much of a concern for an end-user with a single IP address, but the end users of LISP/Ivip would include a non AS-end-user with one or more LISP/Ivip-mapped addresses and two or more links to ISPs. That end-user may find there is wildly varying incoming traffic for the various LISP/Ivip-mapped addresses. Say they want to keep both links from saturating, they might start off with half of their mapped addresses getting their packets through the ETR of ISP-A and the other half from the ETR of ISP-B. Then when one of their LISP/Ivip mapped addresses has a very high rate of incoming traffic, they can keep that on one ETR (say ISP-A's) and change the database to map the others which used that ETR to use the other ETR of ISP-B. This leaves only the busy IP address's traffic on the link from ISP-A. With fine-grained, to individual IP address, control like this, I think there is considerable scope for TE - at least in terms of incoming load balancing across multiple links, ISPs, ETRs etc. - simply by switching the database to cause the ITRs to tunnel packets to a different ETR. This is without any of the TE specific constructs of "Weight" or "Priority" in: http://tools.ietf.org/html/rfc4271#section-9.1.2 I think these are very powerful constructs, but that they would impose a huge burden on ITRs and cause the database to be more complex. I suspect that some or many people tend to think of LISP generally dealing with whole prefixes. I have always thought of LISP and now Ivip dealing both with prefixes and with individual IP addresses. I believe we would have no crisis in routing or addressing - and still have heaps of IPv4 space free - if the global routing system could (and was always able to) easily point any IP address to any edge network. If the global routing system could change this reliably and nearly instantly, without any great cost, that would make full Mobile-IP easy to achieve. Then, IP address space could always have been assigned in smaller chunks and used very efficiently. We definitely can't do this with the global routing system. The propagation of changes is too slow, to unreliable and too costly. The RIBs can't handle 3.75 billion separate routes (for each IP address in the unicast space to 223.255.255.255) and the FIBs aren't up to this either. My aim with Ivip is to keep the BPG system approximately where it is now, to have tens of thousands of ETRs (dumb, cheap and not needing any coordination) in most ISPs and to have a globally coordinated, robust, database and ITR system which can map individual IP addresses - ultimately one or two billion of them - so packets sent to these addresses are tunneled to any ETR in the world. There is a burden on the database, the communications system (push and pull) and on the ITRs for every change in the mapping. So I don't suggest an end-user should be able to flip their mapping every few minutes without incurring some kind of fee to help pay for the burden they place on the system. However, all such changes are a lot less expensive, faster and vastly more fine-grained (single IP addresses rather then 256) than is possible with changing the advertisement of a BGP-prefix. I see a successful LISP or Ivip system as absolutely necessary to contain the growth in the global BGP routing table - and that it would grow to cover a large proportion of the address space, using it extremely efficiently, and so enabling a much greater utilisation of IPv4 address space than is currently the case. Once this happens, LISP/Ivip-mapped addresses will be much more portable and generally useful than IPv6 addresses, assuming the current ban on PI IPv6 space for AS-end-users remains. As long as that restriction remains, and as long as there is no LISP/Ivip system, I believe not many ordinary end-users will take up IPv6. (I think China will adopt it because the government wants each citizen on an individual IP address, where they can be made responsible for the communications - the surveillance system is deeply frustrated by NAT. Also, I expect IPv6 to be adopted by 3G mobile operators, to support Mobile Multimedia Subsystem.) However, if something like LISP/Ivip was created for IPv6, then lots of end-users, including those who have no ASN and don't want to fuss with BGP etc. might start adopting IPv6. I haven't thought much about Ivip for IPv6, but I think it would be nuts to have ITR' FIB having to look at all 128 bits of address to determine the IP address the packet needs to be tunneled to. Even looking at the most significant 64 bits is a major cost, but that may be the best granularity to use: map whole /64 prefixes. >> without additions to the >> protocol stack or changes to operating systems. > > You should know that one of the reasons we took a host based > approach in developing shim6 was because we saw no sign of > a proposal to solve the problem in the routing system. So, now > we have a near-ready host based solution. Why can't we just > let it become ready and see if it works? Why let shim6 be a > distraction here? I believe that SHIM6 won't work for people who want and/or need portability and multihoming control without having to fuss with the operating system configuration of all the affected hosts. So I don't think that we should expect SHIM6 alone to solve the problem of encouraging widespread adoption of IPv6 without PI space for AS-end-users. The only solution I can imagine working is something like LISP or Ivip. Widespread adoption of IPv6 with people doing portability and multihoming with their own PI space being advertised in BGP will quickly bring the IPv6 BGP system to the same router-swamping state we are facing with IPv4. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Jun 25 22:20: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 1I30fO-0007YX-75; Mon, 25 Jun 2007 22:20:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I30fN-0007YP-1Z for ram@iab.org; Mon, 25 Jun 2007 22:20:29 -0400 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I30fL-0007cq-Lk for ram@iab.org; Mon, 25 Jun 2007 22:20:29 -0400 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id l5Q3J9EP008958 for ; Mon, 25 Jun 2007 20:19:09 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id l5Q3J9Ps008955 for ; Mon, 25 Jun 2007 20:19:09 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 25 Jun 2007 20:19:09 -0700 (PDT) From: "william(at)elan.net" To: ram@iab.org Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] In-Reply-To: <46807138.6090705@firstpr.com.au> Message-ID: References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> <46807138.6090705@firstpr.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 also think that current SHIM6 will only get to be used in way similar to NAT where vendor would provide company a router box which like NAT router sits in between local network and internet and can modify ip addresses. Such box would itself add SHIM6 layer data and just like current NAT boxes are also usually DNS servers on local net, it would do similarly. So in effect even if shim6 & v6 designers did not want it, the results would be continuation of NAT in v6 world even when we do have enough addresses. Its not really entirely bad because those NAT boxes also typically work as firewalls for small companies. What could be useful though is if core routers also understand such shim6 or a like scheme and so can look at the packet header and seeing multiple possible destination addresses route address using best appropriate address based on its own BGP table, i.e. its non-ASN routing where instead of ASN the end-poing indicates directly multiple ip blocks that could be used for routing and each one of those is then checked in router table to find ASN and then router decides which ASN is best to route to further. But host-host only multi-homing route that shim6 wants will likely not lead to serious adaption although as an option its good to have. However if we know the above it may well be better to go with slightly different or modified shim6 design that does take into account use in both host-host and endrouter multihoming models. -- William Leibzon Elan Networks william@elan.net _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 26 03:18: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 1I35J7-0001mc-DR; Tue, 26 Jun 2007 03:17:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35J6-0001mS-Qx for ram@iab.org; Tue, 26 Jun 2007 03:17:48 -0400 Received: from smtpout.sgsi.ucl.ac.be ([130.104.5.77] helo=smtp1.sgsi.ucl.ac.be) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I35J6-0007kM-E2 for ram@iab.org; Tue, 26 Jun 2007 03:17:48 -0400 Received: from smtp1.sgsi.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP id EFF742C7EF; Tue, 26 Jun 2007 09:17:05 +0200 (CEST) Received: from [130.104.228.96] (unknown [130.104.228.96]) (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; Tue, 26 Jun 2007 09:17:05 +0200 (CEST) Message-ID: <4680BD70.6030008@uclouvain.be> Date: Tue, 26 Jun 2007 09:17:04 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: "william(at)elan.net" Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> <46807138.6090705@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: Authenticated, X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org William, > > I also think that current SHIM6 will only get to be used in way > similar to NAT where vendor would provide company a router box > which like NAT router sits in between local network and internet > and can modify ip addresses. Such box would itself add SHIM6 > layer data and just like current NAT boxes are also usually > DNS servers on local net, it would do similarly. > > So in effect even if shim6 & v6 designers did not want it, the > results would be continuation of NAT in v6 world even when we do > have enough addresses. Its not really entirely bad because those > NAT boxes also typically work as firewalls for small companies. I agree that enterprise networks will probably want better control on the IPv6 addresses chosen by their shim6 hosts. However, providing this kind of control does not necessarily require the utilization of NAT. A good amount of control can be obtained by placing inside the enterprise network a "controller" that the shim6 hosts would contact when they need to open shim6 flows. The controller could for example order the source and destination IPv6 addresses available to the host to select the most appropriate pair for the traffic engineering objectives of the enterprise. This approach was proposed several years ago, before the creation of the shim6 wg, and could be easily added to shim6, see e.g. http://inl.info.ucl.ac.be/publications/naros-approach-ipv6-multihoming-traffic or http://inl.info.ucl.ac.be/publications/unleashing-traffic-engineering-ipv6-multihomed-sites > What could be useful though is if core routers also understand such > shim6 or a like scheme and so can look at the packet header and > seeing multiple possible destination addresses route address using > best appropriate address based on its own BGP table, i.e. its non-ASN > routing where instead of ASN the end-poing indicates directly > multiple ip blocks that could be used for routing and each one > of those is then checked in router table to find ASN and then > router decides which ASN is best to route to further. I don't think that core routers should have to interpret the shim6 headers and change the addresses Olivier -- http://inl.info.ucl.ac.be , Universite catholique de Louvain, Belgium _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 26 03:44: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 1I35iY-0003g1-VK; Tue, 26 Jun 2007 03:44:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35iY-0003fw-DQ for ram@iab.org; Tue, 26 Jun 2007 03:44:06 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I35iU-0004DJ-0u for ram@iab.org; Tue, 26 Jun 2007 03:44:06 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Jun 2007 09:43:42 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJ5ggEaQ/uCKh2dsb2JhbACBSo1WAQEBCA4s X-IronPort-AV: i="4.16,462,1175464800"; d="scan'208"; a="146494793:sNHT5509401686" 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 l5Q7hf5Z030011; Tue, 26 Jun 2007 09:43:41 +0200 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp263.cisco.com [10.61.65.7]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5Q7hVTC026649; Tue, 26 Jun 2007 07:43:35 GMT Message-ID: <4680C39D.4020505@cisco.com> Date: Tue, 26 Jun 2007 09:43:25 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Robin Whittle Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> <46807138.6090705@firstpr.com.au> In-Reply-To: <46807138.6090705@firstpr.com.au> 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=1137; t=1182843822; x=1183707822; 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=20OK, =20shim6, =20if=20we=20must=20[Re=3A=20[RAM]=20Ivip =20(was=20ViP=20...)] |Sender:=20; bh=ubw2oBPbbXrZPh8sBH2/tGAOa4NUScyFxBpP83kw5ww=; b=hB1HW0fGgEEvcZM3S0w+UyL7UfXvJhJoHNC0uta1ZirGgHi3gmaD1Y/2j1qMEOvs/piQOCYu wLLmBe8kbCrAM6YZ0ihhlFaq7julaHh27n8rbz00vCHG91ivkMg8eYMC; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Brian E Carpenter , 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 Robin, I don't think that SHIM6 is the be-all / end -all solution, but... > Brian Carpenter wrote, in part: > > >> No. If shim6 was shipping code in the popular operating systems, we could >> start the clock on that evaluation. Since it isn't, it's way too soon >> to say anything. >> > > I think it is fair enough to say that if an AS-end-user or an > ISP has a prefix of IP addresses with a bunch of hosts on these > addresses (especially hosts belonging to another organisation) > and they want to multihome that prefix, then they would much > prefer to do the whole thing with a router and some robust, > global, system such as LISP, Ivip or whatever - rather than have > to configure a bunch of disparate host devices, operating > systems etc. to all respond to some centralised control system > so each SHIM6 system behaved as required. > This is the whole point of prefix delegation. The host announces non-ULA non-local scope addresses and away you go. I do think there is a chicken & egg problem with SHIM6, and that's too bad, and that makes this whole argument academic. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 26 04:32: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 1I36NO-00034c-Kx; Tue, 26 Jun 2007 04:26:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I36NM-0002sZ-JS for ram@iab.org; Tue, 26 Jun 2007 04:26:16 -0400 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I36NE-000769-5p for ram@iab.org; Tue, 26 Jun 2007 04:26:16 -0400 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id l5Q9OoYg003013; Tue, 26 Jun 2007 02:24:50 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id l5Q9OoYl003010; Tue, 26 Jun 2007 02:24:50 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 26 Jun 2007 02:24:50 -0700 (PDT) From: "william(at)elan.net" To: Olivier Bonaventure Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] In-Reply-To: <4680BD70.6030008@uclouvain.be> Message-ID: References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> <46807138.6090705@firstpr.com.au> <4680BD70.6030008@uclouvain.be> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Tue, 26 Jun 2007, Olivier Bonaventure wrote: > I agree that enterprise networks will probably want better control on the > IPv6 addresses chosen by their shim6 hosts. However, providing this kind > of control does not necessarily require the utilization of NAT. I should have said "NAT-like" as I do not mean NAT in the way we have it today but rather I mean router device that does ip address translation and which modifies source and/or destination ip address of the packets that path though it (and in case of shim6 that would also mean adding shim6 layer). > A good amount of control can be obtained by placing inside the > enterprise network a "controller" that the shim6 hosts would contact > when they need to open shim6 flows. The controller could for example > order the source and destination IPv6 addresses available to the host > to select the most appropriate pair for the traffic engineering > objectives of the enterprise. It could. But lets imagine a choice between such "controller" device which only works with shim6 layer hosts and a device which you just plugin between your router and switch and which does not require anything specific from hosts (other then support of ip6) and allows to keep existing infrastructure as is but makes entire network suddenly shim6-aware and multi-homed. What do you think IT manager would choose? And BTW, in case you wonder IT manager would not care at all if such device properly fits in the "internet architecture" model, all he/she wants is a device that will "just work"! > This approach was proposed several years ago, before the creation of the > shim6 wg, and could be easily added to shim6, see e.g. > http://inl.info.ucl.ac.be/publications/naros-approach-ipv6-multihoming-traffic > or > http://inl.info.ucl.ac.be/publications/unleashing-traffic-engineering-ipv6-multihomed-sites > >> What could be useful though is if core routers also understand such >> shim6 or a like scheme and so can look at the packet header and >> seeing multiple possible destination addresses route address using >> best appropriate address based on its own BGP table, i.e. its non-ASN >> routing where instead of ASN the end-poing indicates directly >> multiple ip blocks that could be used for routing and each one >> of those is then checked in router table to find ASN and then >> router decides which ASN is best to route to further. > > I don't think that core routers should have to interpret the shim6 > headers and change the addresses While core router vendors and large network operators are slightly more aware of what internet architecture model should look like, in the end such "feature" would not be difficult to add and somebody will try it and then marketing will take it on them to point it one of the reasons why you should buy such and such product (i.e. our device can route better and makes your network more efficient, etc etc). The question however is really more of should architecture be such as to really consider this an "add on" and take advantage of it to create a more functional (but optional) component that helps overall design rather then just leave it to equipment vendors to figure how to do on their own, likely in not entire compatible way. -- William Leibzon Elan Networks william@elan.net _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 26 04:35: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 1I36P9-0004u7-PG; Tue, 26 Jun 2007 04:28:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I36P8-0004u2-Gc for ram@iab.org; Tue, 26 Jun 2007 04:28:06 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I36OT-0007Kk-Av for ram@iab.org; Tue, 26 Jun 2007 04:28:06 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2C8E61986A6; Tue, 26 Jun 2007 11:27:24 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DE37219868B; Tue, 26 Jun 2007 11:27:23 +0300 (EEST) Message-ID: <4680CDEC.6050402@piuha.net> Date: Tue, 26 Jun 2007 11:27:24 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Robin Whittle Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> <46807138.6090705@firstpr.com.au> In-Reply-To: <46807138.6090705@firstpr.com.au> 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: 0a7aa2e6e558383d84476dc338324fab Cc: Brian E Carpenter , 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 Robin, > I think it is fair enough to say that if an AS-end-user or an > ISP has a prefix of IP addresses with a bunch of hosts on these > addresses (especially hosts belonging to another organisation) > and they want to multihome that prefix, then they would much > prefer to do the whole thing with a router and some robust, > global, system such as LISP, Ivip or whatever - rather than have > to configure a bunch of disparate host devices, operating > systems etc. to all respond to some centralised control system > so each SHIM6 system behaved as required. > The preferences depend largely on what you as the user or network owner have an ability to change. What Shim6 gives you is a model where you as the host owner can use multiple addresses even if your organization can not do it for you (no PI, no central devices, etc). Or when you want to be connected to multiple ISPs with different interfaces on your laptop, and the ISPs do not co-operate to give you a single address/prefix. Advantages: no need to change the network side Disadvantages: need to change the hosts. LISP and other solutions on the other hand focus more on the situation where the ISP or the organization is in charge, and being able to provide a multihoming service without any host requirements. Advantages: no need to change the hosts. Disadvantages: need to provide something new in the network. > A primary goal I have > is to enable a LISP/Ivip system to provide effectively portable > IP addresses or prefixes to millions or in principle a billion > or two end-users. > I'm interested in this, but it is an ambitious goal, much more ambitious than merely getting site-based multihoming to work properly and without creating too large global routing tables. Its not clear to me that we want to have a future network where there's a central, coordinated database of what the current locator of each host is. One issue with this is that the dynamics requirements are so demanding in the extreme cases (voip handovers) that it seems end-to-end signaling seems preferrable. > So I don't think that we should expect SHIM6 alone to solve the > problem of encouraging widespread adoption of IPv6 without PI > space for AS-end-users. It is very clear that Shim6 is not a solution that solves the problems we discuss on this list. It solves some problems, but I believe there is consensus that we need other solutions. So lets cut this argument short... Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 26 06:08: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 1I37pu-0004Eb-Q9; Tue, 26 Jun 2007 05:59:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37pt-0004CH-2o for ram@iab.org; Tue, 26 Jun 2007 05:59:49 -0400 Received: from smtpout.sgsi.ucl.ac.be ([130.104.5.77] helo=smtp3.sgsi.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I37pn-0000ZT-9E for ram@iab.org; Tue, 26 Jun 2007 05:59:49 -0400 Received: from smtp3.sgsi.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTP id 9237614286; Tue, 26 Jun 2007 11:59:31 +0200 (CEST) Received: from [130.104.228.96] (unknown [130.104.228.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTP; Tue, 26 Jun 2007 11:59:31 +0200 (CEST) Message-ID: <4680E383.4020904@uclouvain.be> Date: Tue, 26 Jun 2007 11:59:31 +0200 From: Olivier Bonaventure User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: "william(at)elan.net" Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> <46807138.6090705@firstpr.com.au> <4680BD70.6030008@uclouvain.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: Authenticated, X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No 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 Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org William, > >> A good amount of control can be obtained by placing inside the >> enterprise network a "controller" that the shim6 hosts would contact >> when they need to open shim6 flows. The controller could for example >> order the source and destination IPv6 addresses available to the host >> to select the most appropriate pair for the traffic engineering >> objectives of the enterprise. > > It could. But lets imagine a choice between such "controller" device > which only works with shim6 layer hosts and a device which you just > plugin between your router and switch and which does not require > anything specific from hosts (other then support of ip6) and allows > to keep existing infrastructure as is but makes entire network > suddenly shim6-aware and multi-homed. What do you think IT manager > would choose? This "controller" would of course be a piece of software that could be installed on any device already present in the network. We do no necessarily need a new device in the network. Then, the key question becomes when shim6 will be implemented on popular operating systems. We have a Linux implementation that already supports a large fraction of the shim6 drafts, http://inl.info.ucl.ac.be/software/linshim6 but I don't know the status of other OSes As Brian noted a few days ago, we will only be able to judge when shim6 gets implemented on popular OSes. Olivier -- http://inl.info.ucl.ac.be , Universite catholique de Louvain, Belgium _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 26 17:42: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 1I3Int-0004a6-Eb; Tue, 26 Jun 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 1I3Ins-0004YH-CT for ram@iab.org; Tue, 26 Jun 2007 17:42:28 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Imw-00065z-Ce for ram@iab.org; Tue, 26 Jun 2007 17:42:28 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B1EBE212DDE; Wed, 27 Jun 2007 00:41:28 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 710FE212D1A; Wed, 27 Jun 2007 00:41:28 +0300 (EEST) Message-ID: <46818806.90508@nomadiclab.com> Date: Wed, 27 Jun 2007 00:41:26 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Brian E Carpenter , Robin Whittle Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> In-Reply-To: <467FCF66.6090207@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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 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 Brian and Robin: >> I think this >> has to happen soon for IPv4, because the BGP system can't be >> expected to keep up with the growth in the number of advertised >> prefixes. We have to find a way to provide portability, >> multihoming, TE and ideally great mobility for millions of >> end-users, without altering hosts. >> >> SHIM6 would still work with any such LISP or Ivip system for >> IPv6 - so it is "orthogonal" to any such system. However the >> things which SHIM6 would provide would already be largely or >> entirely available via the LISP/Ivip system. > > So what? The approaches are orthogonal, as you say. Shim6 and LISP/Ivip can be combined to allow a multi-interfaced Shim6 host to spread a connection across different access networks, while each access network may use LISP/Ivip internally for multi-homing with multiple providers. Other than this, I don't see an orthogonality between Shim6 and LISP/Ivip. >> and >> does not require any new software or for the host(s) whose >> addresses are being managed to be in any way aware of it. >> Nonetheless, a single host could manage its own LISP/Ivip >> mapping, or some centralised system could perform this task for >> it, for instance to choose the best ETR in a multihoming setting >> when one link fails. > > Yes, that might be a way for users to take control back from ISPs, > although I think shim6 will prove an easier way to do that. Brian, I'm not sure what you mean by "taking control back from ISPs". But in any case, once a multi-homed access network to which a host attaches performs address mapping (through LISP or Ivip), the host can no longer choose between different providers (or ETRs) of that access network. All the host sees is provider-independent addresses. - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Jun 26 18:01: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 1I3J6a-0008R8-7f; Tue, 26 Jun 2007 18:01:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3J6Z-0008Js-6g for ram@iab.org; Tue, 26 Jun 2007 18:01:47 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3J6G-0004iA-Ol for ram@iab.org; Tue, 26 Jun 2007 18:01:47 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 297ED212DDE; Wed, 27 Jun 2007 01:01:28 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E3359212D1A; Wed, 27 Jun 2007 01:01:27 +0300 (EEST) Message-ID: <46818CB5.2070002@nomadiclab.com> Date: Wed, 27 Jun 2007 01:01:25 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Robin Whittle Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> <46807138.6090705@firstpr.com.au> In-Reply-To: <46807138.6090705@firstpr.com.au> 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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Brian E Carpenter , 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 > I think it is fair enough to say that if an AS-end-user or an > ISP has a prefix of IP addresses with a bunch of hosts on these > addresses (especially hosts belonging to another organisation) > and they want to multihome that prefix, then they would much > prefer to do the whole thing with a router and some robust, > global, system such as LISP, Ivip or whatever - rather than have > to configure a bunch of disparate host devices, operating > systems etc. to all respond to some centralised control system > so each SHIM6 system behaved as required. Robin, I wonder why you are so concerned about configuring Shim6. Assuming two communicating hosts both support it, Shim6 should actually work without much configuration -- or even a centralized control system. However, the more intractable problem with Shim6 that I would think of is the requirement for support on both sides of a connection. This may become a chicken-and-egg problem, although it might, e.g., help to add Shim6 support to the requirements in the IPv6 Host Requirements RFC. Ciao, - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jun 27 05: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 1I3Tu0-0003JS-77; Wed, 27 Jun 2007 05:33:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Ttz-0003JM-3T for ram@iab.org; Wed, 27 Jun 2007 05:33:31 -0400 Received: from ik-out-1112.google.com ([66.249.90.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3TtM-0004v6-Qa for ram@iab.org; Wed, 27 Jun 2007 05:33:31 -0400 Received: by ik-out-1112.google.com with SMTP id c29so101910ika for ; Wed, 27 Jun 2007 02:32:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=SvvCFv8yN3NJ9TDK3yTnTvthYiehg2wYvGO214LpLaRaX05jTKixs+wK/a0hR/rPpZ75qizLWWEP8Qeyy9klYqy0eOqce/6mT7NKlKZOV4aRzau7fc4WkzTJtw/UD7gQrf5BCtkTMINMZELrpq9Ap+ktIUU/U57yGp1iMFwmxQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Rj08m8qqOU7g6xmnt2MSIzqaKiNqslYgDwtYiB0Q4CEzXMeDaHhDPWHdFL3CR76afc8ZCF4cOOZI5fe6wBY365CnYUoWKLvb4ggVOMttPs6v3UM4+CclFIJQPdNQBlkDQ9Q4zSsn+2ludkX3UwfTnc84yYVCxCNm22WoIS6Jk10= Received: by 10.78.171.13 with SMTP id t13mr136220hue.1182936771878; Wed, 27 Jun 2007 02:32:51 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id c9sm2352955nfi.2007.06.27.02.32.50 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Jun 2007 02:32:51 -0700 (PDT) Message-ID: <46822EC3.7030806@gmail.com> Date: Wed, 27 Jun 2007 11:32:51 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Olivier.Bonaventure@uclouvain.be Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> <46807138.6090705@firstpr.com.au> <4680BD70.6030008@uclouvain.be> In-Reply-To: <4680BD70.6030008@uclouvain.be> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 2007-06-26 09:17, Olivier Bonaventure wrote: > William, >> >> I also think that current SHIM6 will only get to be used in way >> similar to NAT where vendor would provide company a router box >> which like NAT router sits in between local network and internet >> and can modify ip addresses. Such box would itself add SHIM6 >> layer data and just like current NAT boxes are also usually >> DNS servers on local net, it would do similarly. >> >> So in effect even if shim6 & v6 designers did not want it, the >> results would be continuation of NAT in v6 world even when we do >> have enough addresses. Its not really entirely bad because those >> NAT boxes also typically work as firewalls for small companies. > > I agree that enterprise networks will probably want better control on > the IPv6 addresses chosen by their shim6 hosts. However, providing this > kind of control does not necessarily require the utilization of NAT. A > good amount of control can be obtained by placing inside the enterprise > network a "controller" that the shim6 hosts would contact when they need > to open shim6 flows. The controller could for example order the source > and destination IPv6 addresses available to the host to select the most > appropriate pair for the traffic engineering objectives of the enterprise. > > This approach was proposed several years ago, before the creation of the > shim6 wg, and could be easily added to shim6, see e.g. > http://inl.info.ucl.ac.be/publications/naros-approach-ipv6-multihoming-traffic > > or > http://inl.info.ucl.ac.be/publications/unleashing-traffic-engineering-ipv6-multihomed-sites Exactly. Shim6 will self-deploy without any of that stuff, or any kind of central control, and such things could be added on larger sites if wanted. However, it isn't clear that there will be a gap between small (SOHO and SMB) sites where raw shim6 will self-deploy and need no management, and large sites that will end up using a PI prefix for practical and economic reasons. If there is such a gap, it will need something like a shim6 proxy and/or naros I guess. But raw shim6 would take care of a very large class of small sites. > > > >> What could be useful though is if core routers also understand such >> shim6 or a like scheme and so can look at the packet header and >> seeing multiple possible destination addresses route address using >> best appropriate address based on its own BGP table, i.e. its non-ASN >> routing where instead of ASN the end-poing indicates directly >> multiple ip blocks that could be used for routing and each one >> of those is then checked in router table to find ASN and then >> router decides which ASN is best to route to further. > > > I don't think that core routers should have to interpret the shim6 > headers and change the addresses I agree. Shim6 was designed on a couple of basic assumptions, after all: 1. It must have no negative impact on routing table size, i.e. it works in a world where all prefixes are PA and is of no value or interest to large networks that have a PI prefix. 2. If a site has N ISPs, it will have N PA prefixes (where N=2 in the vast majority of cases). There's a good chance that shim6 for SOHOs and SMBs, plus PI with LISP for larger enterprises, will cover everything and keep the IPv6 DFZ at a very tolerable size. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jun 27 05:39: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 1I3U0D-0006Ij-FR; Wed, 27 Jun 2007 05:39:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3U0B-0006IR-TI for ram@iab.org; Wed, 27 Jun 2007 05:39:55 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Tzt-0006hx-Tk for ram@iab.org; Wed, 27 Jun 2007 05:39:55 -0400 Received: by ug-out-1314.google.com with SMTP id c2so57039ugf for ; Wed, 27 Jun 2007 02:39:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Us3o1Coka1ApcWtiHIig6hAqGoWsy9LrsZR0uBdoSwxO+x9QH0wzEveeFZPW5CZS665SBp/x2F+sZnkqXsdM0SZY1jJ9wIzjVnQZuc5UQGKiQre4sO+BThqWu0JAY6B/jfcyZdKnQica6vUYKlUeqSSp4BelsvURaewel5A1OQE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=dWTAuqy5YwncJPBfLOxFiZAFofmOc70YIjZLUJwA2x1w3OaWyVreHkaGtgThisknPPRwZCkVm23c12EtCA3v76Xwru+GU88+aRp15uTxEymGK7ieJI+WpPEoUWjyLlLNQWi7EndBpZWy7BoNsU4Z1l1c4f1RAqXTHd1z7xFHbJo= Received: by 10.82.152.16 with SMTP id z16mr866123bud.1182937176542; Wed, 27 Jun 2007 02:39:36 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id i3sm2567466nfh.2007.06.27.02.39.35 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Jun 2007 02:39:36 -0700 (PDT) Message-ID: <46823058.6090704@gmail.com> Date: Wed, 27 Jun 2007 11:39:36 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Robin Whittle Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> <46807138.6090705@firstpr.com.au> In-Reply-To: <46807138.6090705@firstpr.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) 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 Robin, > Then what if the central control point has to change? All the > hundreds or thousands of hosts need to be reconfigured. That is a strong argument for making the central mechanism self-deploying (whether it's done via DHCP, a routing protocol, or however). Since we already have to spread RFC 3484 policy from a central point in large enterprises, spreading shim6 policy is really not a new problem. But as I noted just now, I hope this can be avoided. Shim6 was really designed for the ten million small multihomed sites, not for the ten thousand big ones. ... > So I don't think that we should expect SHIM6 alone to solve the > problem of encouraging widespread adoption of IPv6 without PI > space for AS-end-users. We agree on that. I've always expected the big users to have PI prefixes by one method or another. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jun 27 06:19: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 1I3Ucn-0002uT-GN; Wed, 27 Jun 2007 06:19:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Ucm-0002rT-CZ for ram@iab.org; Wed, 27 Jun 2007 06:19:48 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3UZf-0007bX-6G for ram@iab.org; Wed, 27 Jun 2007 06:16:41 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D14D6212DDE; Wed, 27 Jun 2007 13:16:33 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9B7A4212D1A; Wed, 27 Jun 2007 13:16:33 +0300 (EEST) Message-ID: <468238FF.90702@nomadiclab.com> Date: Wed, 27 Jun 2007 13:16:31 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> <46818806.90508@nomadiclab.com> <468231F5.7090809@zurich.ibm.com> In-Reply-To: <468231F5.7090809@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: 9466e0365fc95844abaf7c3f15a05c7d Cc: ram@iab.org, Robin Whittle , Noel Chiappa X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> Brian, I'm not sure what you mean by "taking control back from ISPs". > > Maybe that is a bit strong. But it's clear that if a site has several > providers, and a single PI prefix, there are some tricky issues in the > site controlling which ISP carries which traffic. Yes, but that's exactly the kind of freedom that access network (or site) operators want because it facilitates engineering of traffic coming in and getting out the access network. [...] >> But in any case, once a multi-homed access network to which a host >> attaches performs address mapping (through LISP or Ivip), the host can >> no longer choose between different providers (or ETRs) of that access >> network. All the host sees is provider-independent addresses. > > Yes indeed - LISP/Ivip are natural partners with PI; shim6 is a > natural partner with PA. But they don't damage each other, as > far as I can see. Right. But maybe is good to clarify that LISP/Ivip can be used only for site multi-homing, whereas Shim6 can also be used for host multi-homing. And with respect to site multi-homing, LISP/Ivip takes precedence over Shim6 in that a site doing multi-homing with LISP/Ivip would effectively prevent hosts from managing site multi-homing with Shim6. Best, - Christian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jun 27 08:05: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 1I3WHN-00013b-4c; Wed, 27 Jun 2007 08:05:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3WHL-00013R-RC for ram@iab.org; Wed, 27 Jun 2007 08:05:47 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3WGQ-0002dT-PL for ram@iab.org; Wed, 27 Jun 2007 08:05:47 -0400 Received: by ug-out-1314.google.com with SMTP id c2so80044ugf for ; Wed, 27 Jun 2007 05:04:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hxyT08iL1hHPMIBmyFQeLFaLJuNNGFNKhIB8GSXVMn5EN3B90pzQDiF/HaCBpymf9edTIopIncL1lII36UzCvG6om8QDEoIgM+ShGF0kaEXcWsEpatIwpKnrwO3kiS0xM/pM+8KeVKL7n5FG4k2WtE/OJRQtWuOVF+yRZndRlb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=QvbytZcmsiH2MbVySAEt80dIxp1wdf/uD/OupQgMc1Q5rTsVsMzzs2E3aH7HBYfEpH3FhuBSA75XJltmQFa0nodHvCs56S7YnArwnpURo6DNU3XcCBruSpU5AlNz6tcbi+650Ta1Xe8YtP7t9UQFtON8Xp2G0or4oMgcRRjha/M= Received: by 10.78.159.7 with SMTP id h7mr221611hue.1182945889442; Wed, 27 Jun 2007 05:04:49 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id 7sm6162608nfv.2007.06.27.05.04.48 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Jun 2007 05:04:49 -0700 (PDT) Message-ID: <46825261.8090100@gmail.com> Date: Wed, 27 Jun 2007 14:04:49 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Christian Vogt Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> <46818806.90508@nomadiclab.com> In-Reply-To: <46818806.90508@nomadiclab.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ram@iab.org, Robin Whittle , Noel Chiappa X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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-06-26 23:41, Christian Vogt wrote: > Brian and Robin: ... > Brian, I'm not sure what you mean by "taking control back from ISPs". Maybe that is a bit strong. But it's clear that if a site has several providers, and a single PI prefix, there are some tricky issues in the site controlling which ISP carries which traffic. If the site has a PA prefix per ISP, which is the natural state in IPv6, the site can use address selection policy to control which ISP gets which packet. > But in any case, once a multi-homed access network to which a host > attaches performs address mapping (through LISP or Ivip), the host can > no longer choose between different providers (or ETRs) of that access > network. All the host sees is provider-independent addresses. Yes indeed - LISP/Ivip are natural partners with PI; shim6 is a natural partner with PA. But they don't damage each other, as far as I can see. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jun 27 08:27: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 1I3Wcf-00078U-A2; Wed, 27 Jun 2007 08:27:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Wce-00078A-5d for ram@iab.org; Wed, 27 Jun 2007 08:27:48 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3Wcd-0002AA-7N for ram@iab.org; Wed, 27 Jun 2007 08:27:48 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id E73AF59E40; Wed, 27 Jun 2007 22:27:12 +1000 (EST) Message-ID: <46825796.9090607@firstpr.com.au> Date: Wed, 27 Jun 2007 22:27:02 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> <46818806.90508@nomadiclab.com> <468231F5.7090809@zurich.ibm.com> <468238FF.90702@nomadiclab.com> In-Reply-To: <468238FF.90702@nomadiclab.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: Christian Vogt , Brian E Carpenter , Noel Chiappa X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org There are a number of recent messages which I would like to respond to, but for now I will just reply to two things mentioned by Christian Vogt: > Right. But maybe is good to clarify that LISP/Ivip can be used only for > site multi-homing, whereas Shim6 can also be used for host multi-homing. It has never been my vision that LISP (or Ivip, which is not yet two weeks old) is only capable of, or should only be used for, controlling the tunneling of packets to ETRs in large groups, meaning subnets or prefixes like those typically handled by BPG. So I have never thought they "can be used only for site multi-homing". Also, I think my view of how addresses wind up in the LISP/Ivip system is rather different from what the LISP proponents and maybe others have in mind. I have written about this in the long messages listed at: http://www.firstpr.com.au/ip/ivip/ , especially: http://www1.ietf.org/mail-archive/web/ram/current/msg01561.html The database and ITRs are a massive piece of infrastructure and if we ensure they are able to handle millions to hundreds of millions of different mappings, including for individual IPv4 addresses, then we will gain benefits far beyond multihoming and TE at site-granularity. Firstly, we can slice and dice and move the physical destination of one or more billions of IPv4 addresses with arbitrary finesse in the dimensions of both time and address-space. This will never be possible with the global BGP system. I don't suggest that the granularity for an IPv6 Ivip system be all the way to a /128. To a /64 sounds more realistic. This enables the most important goal I see: the more efficient use of IPv4 address space - without further burdening the BGP system. This address space can be assigned without a care about route aggregation or the binary boundaries of conventional prefixes. This means it can be dealt out in small chunks, like one or a few or a hundred or whatever IP addresses as people need them, not the overblown traditional PI allocation of 256, 512, 1024, . . . 16,384 . . . IP addresses which are "big enough for expansion over the next few years" - expansion which often never happens. The second immensely valuable benefit is that this ITR infrastructure can beam packets around the Net to ETRs which are actually what I call Translating Tunnel Routers - which have two-way tunnels to nearby truly mobile devices. That would completely transform mobile IP, by enabling the mobile nodes to pick the nearest TTRs, wherever they are (inside or outside edge networks). Path lengths would be close to optimal, no matter where the mobile node and corresponding nodes are. The mobile nodes don't require any special handling by the edge network, and they can be behind NAT too. There are serious questions of scaling here, in terms of the number of address divisions the ITRs and the database handles and the frequency of updates. There probably needs to be an extra charge for updates, or updates above a certain rate. Maybe there could be two or more Ivip systems, covering different ranges of addresses. One could have low fees and generally do updates at a rate suitable for multihoming. Another could be optimised for more rapid changes in mapping. I am not convinced two or more systems would be good, but I don't rule it out. Anyone could roll out such a system today, as a revenue generating business, as long as their RIR approved of their address space being used for this novel purpose. There would need to be either a bunch of standardised ETRs in edge networks, with local routing support for the Ivip-mapped addresses, or the operators would need TTRs all around the Net, so their customers could put their hosts on an IP address in any nearby edge network and install a little piece of tunnel software to tunnel incoming and outgoing packets to the TTRs. Any global ITR and database system, whether it is LISP or Ivip or whatever, will be a truly heroic, bold, architectural enhancement for the Internet. We might as well do a proper job of it. > And with respect to site multi-homing, LISP/Ivip takes precedence over > Shim6 in that a site doing multi-homing with LISP/Ivip would effectively > prevent hosts from managing site multi-homing with Shim6. SHIM6 couldn't work normally with /128 specific Ivip, because the HBA address generation would need to be done by the host and the Ivip system's mapping made to match each such address, for each ISP. However, if the host had a whole /64 via Ivip, or two such /64s via different ISPs, then it could do SHIM6 multihoming fine. I am not sure what purpose would be served, because Ivip could provide a whole /64 multihomed via two ISPs anyway. This would require ETRs in each ISP and support for the /64 in the ISP's routing system, including to allow packets out with source addresses in this range. SHIM6 doesn't require anything from networks. All it needs is appropriate software in all the hosts, and two IP addresses from two links to two ISPs, and it can do multihoming. SHIM6 is only going to be for IPv6, and only widely used some years after it is finalised, when sufficient operating systems and devices (3G cellphones etc.) support it properly. I doubt if anyone would want to multihome with SHIM6 if even a small fraction of the hosts they are trying to communicate with couldn't follow their host to its second IP address. SHIM6 can't provide the global portability (or mobility) of IP addresses or whole prefixes of addresses which LISP/Ivip can provide. But SHIM6 is free, autonomous and self- contained - and doesn't require thousands of souped-up routers, a huge, fast, distributed yet in some way centralised database and all the money, administration and tortuous policy debates that will entail! - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Jun 27 23:33: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 1I3klA-0003rN-4G; Wed, 27 Jun 2007 23:33:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3kl9-0003mQ-1F for ram@iab.org; Wed, 27 Jun 2007 23:33:31 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3kku-0003r2-Pl for ram@iab.org; Wed, 27 Jun 2007 23:33:31 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKB005LBTP7G5@szxga01-in.huawei.com> for ram@iab.org; Thu, 28 Jun 2007 11:29:31 +0800 (CST) Received: from m50376k ([10.111.12.130]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKB008OBTP6HJ@szxga01-in.huawei.com> for ram@iab.org; Thu, 28 Jun 2007 11:29:31 +0800 (CST) Date: Thu, 28 Jun 2007 11:29:30 +0800 From: Michael To: dino@cisco.com Message-id: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ram@iab.org Subject: [RAM] the separation of ID/RLOC X-BeenThere: ram@iab.org X-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="===============0053466179==" Errors-To: ram-bounces@iab.org This is a multi-part message in MIME format. --===============0053466179== Content-type: multipart/alternative; boundary="Boundary_(ID_SCnFHblzNRa1VOh7mmdxpQ)" This is a multi-part message in MIME format. --Boundary_(ID_SCnFHblzNRa1VOh7mmdxpQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, Dino, As I spot, in LISP1, LISP1.5, there is no a complete separation bwtween ID/RLOC , because, within a site, a EID still play both roles at the same time, in LISP2 & LISP3, EIDs are said to be unroutable, I do not really understand, here I guess that you mean EIDs are not routable among ISPs, like Tier-1 etc, they are still routable inside a site. If I am wrong, how devices inside a site can be routed? best, Michael --Boundary_(ID_SCnFHblzNRa1VOh7mmdxpQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi, Dino,
 
As I spot, in LISP1, LISP1.5, there is no a complete separation bwtween ID/RLOC , because, within a site, a EID still play both roles at the same time, in LISP2 & LISP3, EIDs are said to be unroutable, I do not really understand, here I guess that you mean EIDs are not routable among ISPs, like Tier-1 etc, they are still routable inside a site. If I am wrong, how devices inside a site can be routed?  
 
best,
 
Michael
--Boundary_(ID_SCnFHblzNRa1VOh7mmdxpQ)-- --===============0053466179== 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 --===============0053466179==-- From ram-bounces@iab.org Thu Jun 28 07:46: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 1I3sRp-0001b1-Mk; Thu, 28 Jun 2007 07:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3sRp-0001av-21 for ram@iab.org; Thu, 28 Jun 2007 07:46:05 -0400 Received: from ik-out-1112.google.com ([66.249.90.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3sRk-0002rg-No for ram@iab.org; Thu, 28 Jun 2007 07:46:05 -0400 Received: by ik-out-1112.google.com with SMTP id c29so640672ika for ; Thu, 28 Jun 2007 04:45:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=TL2VIsPfARn+a/5RxVcJEvJ6DGZ2MPjhgQJvIt36azGOSR+Se6S9xEvdixU/JD7XSOnpjvH0xb/O7mipUiCJ/cLp1IYhxzx42jIhqjOMELqoJdy7bMa8vtzyp40ymkmfBTSZiVddSKGJGLWlz9dB92G7pBBiWF3u9dBZn0amuCA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=FXWcN89pU5EGhEYuVwXi7niHanUEgg9Un8EsUhD6RmajweNd46c8uLUz93QgoDt3IthYUVTJ/FwtcXvCGD4gRoPSXxCyLVVlS/zIUlzQSUzGYxTg/quv0nAa+CMHImKS5U2sUv/V4GVGcGGV0TQ7c9lh8MZJOupWgxP6AxiMW48= Received: by 10.78.201.2 with SMTP id y2mr841062huf.1183031158697; Thu, 28 Jun 2007 04:45:58 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id 2sm4114840nfv.2007.06.28.04.45.57 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Jun 2007 04:45:58 -0700 (PDT) Message-ID: <46839F77.70004@gmail.com> Date: Thu, 28 Jun 2007 13:45:59 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] DNS usage in NERD References: <467D0D7F.60406@firstpr.com.au> In-Reply-To: <467D0D7F.60406@firstpr.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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-06-18 15:30, Robin Whittle wrote: > Brian wrote: > >> > Indeed, but how can you impose a constraint that DNS zone transfers >> > etc do not in any way depend on NERD/LISP? That is where I am >> > puzzled. > > Wouldn't it be good enough that LISP/Ivip or whatever states in > its architectural RFC that addresses which depend on this > mapping scheme should not be used for certain purposes, including?: > > 1 - BGP routers, including ITRs and ETRs - obviously. > > 2 - Root and TLD nameservers. Probably many second level > nameservers such as .com.au. too. Probably including > any nameserver which does something under in-addr.arpa > on which anyone else's but the operator's addresses > depend upon for reverse mapping. > > 3 - Any nameserver on which the mapping scheme depends. > > 4 - Whatever central database servers control the mapping > system, including interfaces for user control of mapping > of their IP addresses, servers for all push and pull update > activities and any independent systems which monitor > where a mobile host is connecting, and automatically > initiate changes to the mapping database if the mobile > host's current link fails. > > Then all the critical nameservers have ordinary BGP-accessible > addresses, so their zone transfers go via ordinary BGP, > irrespective of what the mapping system does. I think I would prefer Eliot to comment on getting the circularity out of NERD, but my reaction is that this list of constraints may well be necessary and sufficient, but it's operationally error-prone. So I want to remove all possible dependencies for something so basic as bootstrapping the mapping database. I'm sticking to my own suggestion: use well-known IP addresses to bootstrap NERD, thereby avoiding any possible circular dependency involving DNS by construction. I certainly agree that enumerating the addresses that must never be mapped, to avoid circularity, is a good thing. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 28 11:03: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 1I3vWn-0004fL-Sh; Thu, 28 Jun 2007 11:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3vWm-0004a6-K0 for ram@iab.org; Thu, 28 Jun 2007 11:03:24 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3vWS-0008ME-PK for ram@iab.org; Thu, 28 Jun 2007 11:03:24 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 Jun 2007 11:03:04 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAL9qg0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,471,1175486400"; d="scan'208"; a="63900553:sNHT80364492" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5SF34el005359; Thu, 28 Jun 2007 11:03:04 -0400 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 l5SF2sZN022066; Thu, 28 Jun 2007 15:02:59 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 11:02:46 -0400 Received: from [192.168.0.5] ([10.82.208.110]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 11:02:45 -0400 In-Reply-To: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dino Farinacci Date: Thu, 28 Jun 2007 08:02:43 -0700 To: Michael X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 28 Jun 2007 15:02:45.0863 (UTC) FILETIME=[62964770:01C7B995] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=843; t=1183042984; x=1183906984; c=relaxed/simple; s=rtpdkim2001; 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=20the=20separation=20of=20ID/RLOC |Sender:=20 |To:=20Michael=20; bh=j3UfYfPVhhdZXSZr1n/pJLivSfGzOvR2x9AQdem34KI=; b=XjZlQ08fVWwB1ocjRg5zpE4fQGf7h4xo1pQqfGcS/D8Vtj1I6jnpsbyBBkIIWoGHZTAVXsID msEd+YxKiaH7puVqpwTBkcoWm8UngrRbJoGXt6EPeQkBdsom4K4a5Kcy; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ram@iab.org Subject: [RAM] Re: the separation of ID/RLOC X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 spot, in LISP1, LISP1.5, there is no a complete separation > bwtween ID/RLOC , because, within a site, a EID still play both > roles at the same time, in LISP2 & LISP3, EIDs are said to be > unroutable, I do not really understand, here I guess that you mean > EIDs are not routable among ISPs, like Tier-1 etc, they are still > routable inside a site. If I am wrong, how devices inside a site > can be routed? The ID/RLOC split is for global communication. Which means outside of the site. So yes, an EID is routeable within a site and there is no split because the packet hasn't hit an ITR yet. When the packet reaches an ITR, the packet is typically destined for a destination outside of the site. At that point the ITR prepends a header where the addresses in the outer header are RLOCs. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 28 12:27: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 1I3wpl-0002IQ-D8; Thu, 28 Jun 2007 12:27:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3wpk-0002IG-FN for ram@iab.org; Thu, 28 Jun 2007 12:27:04 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3wpF-0007qs-Aa for ram@iab.org; Thu, 28 Jun 2007 12:27:04 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Jun 2007 18:26:24 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAG5+g0aQ/uCLh2dsb2JhbACBT41cAgkOLA X-IronPort-AV: i="4.16,471,1175464800"; d="scan'208"; a="146782484:sNHT76406948" 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 l5SGQNBD021936; Thu, 28 Jun 2007 18:26:23 +0200 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp4262.cisco.com [10.61.80.165]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5SGQMTC001771; Thu, 28 Jun 2007 16:26:23 GMT Message-ID: <4683E125.4070800@cisco.com> Date: Thu, 28 Jun 2007 18:26:13 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [RAM] DNS usage in NERD References: <467D0D7F.60406@firstpr.com.au> <46839F77.70004@gmail.com> In-Reply-To: <46839F77.70004@gmail.com> 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=871; t=1183047983; x=1183911983; 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]=20DNS=20usage=20in=20NERD |Sender:=20; bh=nuQF0fw7NXWeF8nE9ursB22wtEeav3dlECBxcQMEWFk=; b=UBRsepqEjtMngThxOz9NNn5iAMcAaqsDljq8t0KYQlXS5lKny+OXWcA9BC+HIn673UsG/0ma 2HtIDmTL1p4y8kmdn4RHugTiw+hw+bUObMJGD5p88aG9Fbuz3I4/Cqtb; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 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 Brian E Carpenter wrote: > I'm sticking to my own suggestion: use well-known IP addresses > to bootstrap NERD, thereby avoiding any possible circular dependency > involving DNS by construction. Why not? You could even boost all the NERDs and distribute them without any change to the existing spec. All you need to do is advertise those addresses and have some method of scaling their use. > > I certainly agree that enumerating the addresses that must never > be mapped, to avoid circularity, is a good thing. Again, that's an easy check: anything in the NERD should not be used by infrastructure critical to LISP itself. In fact, anyone could verify that this is true by stepping through the infrastructure itself and looking up associated IP addresses of web servers, name servers, etc. Let's not confuse mechanism for resource. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 28 20:59: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 1I44pp-0004jd-UQ; Thu, 28 Jun 2007 20:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I44po-0004f8-Dj for ram@iab.org; Thu, 28 Jun 2007 20:59:40 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I44pj-0001lO-Qn for ram@iab.org; Thu, 28 Jun 2007 20:59:40 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 0245659DA1; Fri, 29 Jun 2007 10:59:31 +1000 (EST) Message-ID: <46845967.9080302@firstpr.com.au> Date: Fri, 29 Jun 2007 10:59:19 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] DNS usage in NERD References: <467D0D7F.60406@firstpr.com.au> <46839F77.70004@gmail.com> In-Reply-To: <46839F77.70004@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Brian Carpenter wrote: > I'm sticking to my own suggestion: use well-known IP addresses > to bootstrap NERD, thereby avoiding any possible circular dependency > involving DNS by construction. Assuming there will be a single LISP/Ivip, the new system will be a centrally planned, permanent, piece of infrastructure. I think it would be feasible and desirable in terms of simplicity to reserve particular IP addresses for particular functions which are in any way crucial to LISP/Ivip. This shouldn't mean a single point of failure, if UDP communications to a set of anycast servers can perform the functions required. For TCP the separate servers idea wouldn't be so robust, so it should be possible to use set of anycast routers with private network tunnels to a central or distributed server farm. Like the root nameservers, the router and servers at these addresses would need to be able to withstand any botnet attack which is likely to be launched. That threat will grow with as more PCs have faster upstream links, such as with fibre to the premises, as Verizon is now having great success with. > I certainly agree that enumerating the addresses that must never > be mapped, to avoid circularity, is a good thing. I agree. It might be best to have a config file in every ITR for ranges of addresses to which packets will never be tunneled. This would remove the danger of malicious or accidental database changes being received which would, without the config file limits, would cause packets to be tunneled to infrastructure-critical addresses. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Jun 28 21:48: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 1I45bR-0005A0-Ov; Thu, 28 Jun 2007 21:48:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I45bP-00059v-VS for ram@iab.org; Thu, 28 Jun 2007 21:48:51 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I45aK-0001Ad-Gc for ram@iab.org; Thu, 28 Jun 2007 21:48:51 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKD007IWJM2RB@szxga03-in.huawei.com> for ram@iab.org; Fri, 29 Jun 2007 09:46:50 +0800 (CST) Received: from m50376k ([10.111.12.130]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKD009WCJM0BD@szxga03-in.huawei.com> for ram@iab.org; Fri, 29 Jun 2007 09:46:50 +0800 (CST) Date: Fri, 29 Jun 2007 09:46:49 +0800 From: Michael To: Dino Farinacci Message-id: <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ram@iab.org Subject: [RAM] Re: the separation of ID/RLOC X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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, This is a overlay model, ISPs can be treated as a tranport network. If we do not consider the mobility too much in this phrase, this proposal works fine. If the mobility must be supported in the future, the mapping becomes complicated, of course, the candidate solutions will be based on the some basic assumption: the dimension of moving network, that is, whether the majority part of the Internet can move arbitarily or just a small part can be allowed to move. Anyway, if the mobility will be well supported, the reliability and timeliness of the mapping mechanisms would be the critical issue. Michael ----- Original Message ----- From: "Dino Farinacci" To: "Michael" Cc: Sent: Thursday, June 28, 2007 11:02 PM Subject: Re: the separation of ID/RLOC >> As I spot, in LISP1, LISP1.5, there is no a complete separation >> bwtween ID/RLOC , because, within a site, a EID still play both >> roles at the same time, in LISP2 & LISP3, EIDs are said to be >> unroutable, I do not really understand, here I guess that you mean >> EIDs are not routable among ISPs, like Tier-1 etc, they are still >> routable inside a site. If I am wrong, how devices inside a site >> can be routed? > > The ID/RLOC split is for global communication. Which means outside of > the site. So yes, an EID is routeable within a site and there is no > split because the packet hasn't hit an ITR yet. When the packet > reaches an ITR, the packet is typically destined for a destination > outside of the site. At that point the ITR prepends a header where > the addresses in the outer header are RLOCs. > > Dino > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 29 00:31: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 1I488d-0003RS-KM; Fri, 29 Jun 2007 00:31:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I488b-0003M4-9t for ram@iab.org; Fri, 29 Jun 2007 00:31:17 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I488b-0003dU-20 for ram@iab.org; Fri, 29 Jun 2007 00:31:17 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 28 Jun 2007 21:31:17 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPImhEarR7O6h2dsb2JhbACPLAIJDiw X-IronPort-AV: i="4.16,473,1175497200"; d="scan'208"; a="382576021:sNHT26930386" 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 l5T4VGTY008804; Thu, 28 Jun 2007 21:31:16 -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 l5T4VBms027840; Fri, 29 Jun 2007 04:31:15 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 21:31:12 -0700 Received: from [192.168.0.5] ([10.21.114.113]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 21:31:12 -0700 In-Reply-To: <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28BCD4CA-4B52-4812-A01B-A5B144B0D9CE@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Date: Thu, 28 Jun 2007 21:31:11 -0700 To: Michael X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Jun 2007 04:31:12.0335 (UTC) FILETIME=[52B285F0:01C7BA06] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=696; t=1183091476; x=1183955476; 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=20the=20separation=20of=20ID/RLOC |Sender:=20; bh=zyYM3TqdeT8OU0YTAzkUbj7zmcMxOlhVgTDS+Sx0338=; b=fH0VfZunu6ri0HvUyAJQC+k9dJ7mRYnzo58xi/ZgMxdlrABuSWY2Ofu8Y/qvoB+A8I1GSl6z OCC/VtSrdYZfznT5BuOKL3U7nEn3O//JhyXNlh9kAlK8BOFbNf3NOEKK; 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ram@iab.org Subject: [RAM] Re: the separation of ID/RLOC X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > This is a overlay model, ISPs can be treated as a tranport network. > If we do not consider the mobility too much in this phrase, this > proposal works fine. If the mobility must be supported in the > future, the mapping becomes complicated, of course, the candidate > solutions will be based on the some basic assumption: the dimension > of moving network, that is, whether the majority part of the > Internet can move arbitarily or just a small part can be allowed to > move. Anyway, if the mobility will be well supported, the > reliability and timeliness of the mapping mechanisms would be the > critical issue. Yep, agree with everything you wrote. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 29 03:45: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 1I4BAP-0001Dj-R6; Fri, 29 Jun 2007 03:45:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4BAO-00016M-Hh for ram@iab.org; Fri, 29 Jun 2007 03:45:20 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4BA7-0004sy-10 for ram@iab.org; Fri, 29 Jun 2007 03:45:20 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A67B2212DAC; Fri, 29 Jun 2007 10:45:01 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5F8AE212D0E; Fri, 29 Jun 2007 10:45:01 +0300 (EEST) Message-ID: <4684B87B.5030803@nomadiclab.com> Date: Fri, 29 Jun 2007 10:44:59 +0300 From: Christian Vogt User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Michael Subject: Re: [RAM] Re: the separation of ID/RLOC References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> In-Reply-To: <002e01c7b9ef$5c453430$820c6f0a@china.huawei.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: 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 Michael, update speed and reliability of the mapping function are not just needed for access network mobility. Its also needed for provider fail-over. Access network operators want to be able to switch providers quickly when one goes down. This is one of the main goals for multi-homing. Fast provider fail-over requires a very agile mapping function, however. To me, it is not clear how either a pull or a push model, or a trade-off between the two, can support this in a scalable manner. - Christian Michael wrote: > Hi, Dino, > > This is a overlay model, ISPs can be treated as a tranport network. > If we do not consider the mobility too much in this phrase, this > proposal works fine. If the mobility must be supported in the future, > the mapping becomes complicated, of course, the candidate solutions > will be based on the some basic assumption: the dimension of moving > network, that is, whether the majority part of the Internet can move > arbitarily or just a small part can be allowed to move. Anyway, if > the mobility will be well supported, the reliability and timeliness > of the mapping mechanisms would be the critical issue. > > Michael _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 29 03:53: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 1I4BI2-0004uK-8K; Fri, 29 Jun 2007 03:53:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4BI0-0004u8-Mq for ram@iab.org; Fri, 29 Jun 2007 03:53:12 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4BHc-0007Fq-Cw for ram@iab.org; Fri, 29 Jun 2007 03:53:12 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKE00L4N0IFTX@szxga01-in.huawei.com> for ram@iab.org; Fri, 29 Jun 2007 15:51:51 +0800 (CST) Received: from m50376k ([10.111.12.130]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKE00AZA0IDI0@szxga01-in.huawei.com> for ram@iab.org; Fri, 29 Jun 2007 15:51:51 +0800 (CST) Date: Fri, 29 Jun 2007 15:51:49 +0800 From: Michael Subject: Re: [RAM] Preliminary thoughts on LISP 1.5 To: Robin Whittle , ram@iab.org Message-id: <01cf01c7ba22$59aaf920$820c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20070620183547.GA24174@cisco.com> <467F6708.2060400@firstpr.com.au> X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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: "Robin Whittle" To: Sent: Monday, June 25, 2007 2:56 PM Subject: Re: [RAM] Preliminary thoughts on LISP 1.5 > Hi Vince, > > I have read your email carefully at least three times and I > still don't have a clear understanding of what you are trying to > describe. > > Can you or anyone else provide examples, with more concrete > descriptions, diagrams etc. for each point? For instance, I > couldn't develop a clear example in my mind of any one of your > options for point 1. > > I recognise point 6 as being similar to what I thought > distinguished my Ivip idea from LISP. As far as I knew, apart > from maybe LISP 1.0 (which I understand is a conceptual stage > rather than something which helps reduce the size of the BGP > routing table), for all other LISP variants the (EID) addresses > mapped by the system (to ETR addresses) were not within any > prefix which was advertised by a BGP router. But in this > message you raise the possibility of a new construct: an LTA > (LISP Translation Aggregator). Point 6 mentions a (sub)set of > LTAs advertising "their aggregated EID-to-RLOC mappings" to the > existing global routing table. Maybe that means something like > what I propose for Ivip ITRs. > according to the LISP, their aggregattion degree of EID-to-RLOC mappings depends on where the ITRs are allocated. > Dino protested on 15 June (Re: ViP: Anycast ITRs in the DFZ & > mobile tunnels): > >> Robin, this is LISP 1.5, don't you realize that? In LISP 1.5, >> when EIDs come out of PI space, they cannot be routeable via >> the BGP Internet, so they use another topology that does carry >> EIDs. This is exactly what you are describing above. > > You and probably Dino have a much more concrete idea of LISP 1.5 > than I am able to create in my own mind by reading what little I > have to go on. > > I am not convinced Dino understood correctly what I had in mind > when I wrote my first piece. Hopefully, seven long Ivip > messages since then will enable anyone with sufficient patience > to have a clearer idea of what I am trying to communicate. I > plan to write a much more accessible I-D in August. For now, > links to the longer messages I wrote are at: > > http://www.firstpr.com.au/ip/ivip/ > > I got no idea from your LISP I-D: > > LISP 1.5: where EIDs are routable for bootstrapping > EID-to-RLOC mappings; such routing is via a > separate topology. > > that LISP 1.5 involved any router advertising prefixes > containing EID addresses to the rest of the BGP system. > > It is five months since you released the LISP I-D and I suspect > I am not the only one who is struggling to create a concrete > example in their minds of LISP 1.5. Anything you can write by > way of examples would really help. > > - Robin > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 29 04:03: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 1I4BRj-00042G-M9; Fri, 29 Jun 2007 04:03:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4BRi-0003qQ-7C for ram@iab.org; Fri, 29 Jun 2007 04:03:14 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4BRh-0006q8-Il for ram@iab.org; Fri, 29 Jun 2007 04:03:14 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKE00B6210AMM@szxga03-in.huawei.com> for ram@iab.org; Fri, 29 Jun 2007 16:02:34 +0800 (CST) Received: from m50376k ([10.111.12.130]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKE00HC9109H5@szxga03-in.huawei.com> for ram@iab.org; Fri, 29 Jun 2007 16:02:34 +0800 (CST) Date: Fri, 29 Jun 2007 16:02:33 +0800 From: Michael Subject: Re: [RAM] Re: the separation of ID/RLOC To: Christian Vogt Message-id: <01d601c7ba23$d96560f0$820c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> 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 Hi, Christian, ----- Original Message ----- From: "Christian Vogt" To: "Michael" Cc: "Dino Farinacci" ; Sent: Friday, June 29, 2007 3:44 PM Subject: Re: [RAM] Re: the separation of ID/RLOC > Michael, > > update speed and reliability of the mapping function are not just needed > for access network mobility. Its also needed for provider fail-over. > > Access network operators want to be able to switch providers quickly > when one goes down. This is one of the main goals for multi-homing. > This is the basic requirement on the mapping mechanism. > Fast provider fail-over requires a very agile mapping function, however. > To me, it is not clear how either a pull or a push model, or a > trade-off between the two, can support this in a scalable manner. This is the key part of the mapping mechanism. I believe that at the first step some prototype systems based on DNS (pull model) and DHT (Push model) or some hybrid model respectively must be deployed and test their performance, then decide which mechanism is a good one. The mobility support has some impact on which model will be adopted. Michael > > - Christian > > > Michael wrote: >> Hi, Dino, >> >> This is a overlay model, ISPs can be treated as a tranport network. >> If we do not consider the mobility too much in this phrase, this >> proposal works fine. If the mobility must be supported in the future, >> the mapping becomes complicated, of course, the candidate solutions >> will be based on the some basic assumption: the dimension of moving >> network, that is, whether the majority part of the Internet can move >> arbitarily or just a small part can be allowed to move. Anyway, if >> the mobility will be well supported, the reliability and timeliness >> of the mapping mechanisms would be the critical issue. >> >> Michael > > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Jun 29 13:54: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 1I4Kfx-0003YM-AN; Fri, 29 Jun 2007 13:54:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Kfv-0003YF-W1 for ram@iab.org; Fri, 29 Jun 2007 13:54:32 -0400 Received: from m106.maoz.com ([205.167.76.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4Kfv-0003Hk-Jw for ram@iab.org; Fri, 29 Jun 2007 13:54:31 -0400 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l5THsEoI005005; Fri, 29 Jun 2007 10:54:14 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l5THsEwF005004; Fri, 29 Jun 2007 10:54:14 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 29 Jun 2007 10:54:14 -0700 From: David Meyer To: ram@iab.org Message-ID: <20070629175414.GA4939@1-4-5.net> MIME-Version: 1.0 X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I laugh and I cry, and I'm haunted by...Things I never meant nor wished to say" -- Bob Dylan, "When The Deal Goes Down" User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: sbrim@cisco.com Subject: [RAM] Just posted: draft-meyer-lisp-cons-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: , Content-Type: multipart/mixed; boundary="===============1170516657==" Errors-To: ram-bounces@iab.org --===============1170516657== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks,=20 I just posted "LISP-CONS: A Content distribution Overlay Network Service for LISP" (draft-meyer-lisp-cons-00.txt). I also put it on http://www.1-4-5.net/~dmm/draft-meyer-lisp-cons-00.txt=20 if you want to get a look before the good folks at the IETF get a chance to post it. As always, comments are greatly appreciated. Dave (for Dino, Darrel, Vince, and Scott) --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFGhUdGORgD1qCZ2KcRAj/qAKCUxQQyKaUKsOZjTL/Voe0eMLwnuQCgiy5u lsaJfkUKbgV9GZqL30c+h54= =/7bc -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- --===============1170516657== 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 --===============1170516657==-- From ram-bounces@iab.org Fri Jun 29 22:14: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 1I4STZ-0005I4-07; Fri, 29 Jun 2007 22:14:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4STY-0005GQ-7M for ram@iab.org; Fri, 29 Jun 2007 22:14:16 -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 1I4STT-0001yA-Sy for ram@iab.org; Fri, 29 Jun 2007 22:14:16 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 29 Jun 2007 19:14:11 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAM5YhUarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,477,1175497200"; d="scan'208"; a="499021921:sNHT26162604" 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 l5U2EB7W012495; Fri, 29 Jun 2007 19:14:11 -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 l5U2EAka023940; Sat, 30 Jun 2007 02:14:10 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); Fri, 29 Jun 2007 19:14:10 -0700 Received: from [192.168.39.54] ([10.21.113.155]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 19:14:10 -0700 In-Reply-To: <4684B87B.5030803@nomadiclab.com> References: <005201c7b934$89e6f100$820c6f0a@china.huawei.com> <002e01c7b9ef$5c453430$820c6f0a@china.huawei.com> <4684B87B.5030803@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <87CA5DB9-00CE-4CE5-8FCA-4CDB30ADC9C4@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Re: the separation of ID/RLOC Date: Fri, 29 Jun 2007 07:11:21 -0700 To: Christian Vogt X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 30 Jun 2007 02:14:10.0197 (UTC) FILETIME=[58559450:01C7BABC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=812; t=1183169651; x=1184033651; 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]=20Re=3A=20the=20separation=20of=20ID/RLOC |Sender:=20; bh=dE1V6wF1poM6moy3kxu8Tk7PWwv6+sjAjIUUpAdUVjg=; b=ZZo1KYUQLm5lcjC1Wn6dBF/2JHZAc/5Gp6HcmYtpUadmlAm5TzoyFbfeJWpVYYrgHzwg+cka 9SlldLtBBIhD4KXR+eRcEEHEMrlbrXyFddAkC4oYY82UTUNkxzXGUvaZWvldTB6KZ+BbvPIqz5 Ja6WJ8hAHNbXjLhvejD/cZHOk=; 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: 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 > update speed and reliability of the mapping function are not just > needed > for access network mobility. Its also needed for provider fail-over. It is needed as well for regular packet forwarding when nodes are stationary. > Access network operators want to be able to switch providers quickly > when one goes down. This is one of the main goals for multi-homing. For what value of "quickly"? Please quantify. > Fast provider fail-over requires a very agile mapping function, > however. It all depends on change frequency and the level of granularity is required. So please quantify. > To me, it is not clear how either a pull or a push model, or a > trade-off between the two, can support this in a scalable manner. Or just keep it out of the mapping service. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jun 30 03:30: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 1I4XPO-0004IU-NX; Sat, 30 Jun 2007 03:30:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4XPN-0004IP-Tl for ram@iab.org; Sat, 30 Jun 2007 03:30:17 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4XPM-000266-JL for ram@iab.org; Sat, 30 Jun 2007 03:30:17 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 408A859E3E; Sat, 30 Jun 2007 17:29:18 +1000 (EST) Message-ID: <46860642.2080606@firstpr.com.au> Date: Sat, 30 Jun 2007 17:29:06 +1000 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Just posted: draft-meyer-lisp-cons-00.txt References: <20070629175414.GA4939@1-4-5.net> In-Reply-To: <20070629175414.GA4939@1-4-5.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: sbrim@cisco.com X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: 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 Dave, I read your I-D and have some questions, observations, suggestions etc. In the Map Reply message, I think there needs to be some information on how long to cache the results for. Likewise, in the "Unreachable" message. I understand the "Unreachable" message means that the EID in the request is not within any prefix which any CAR known to the system is currently authoritative for. Ideally, the requester would be told to cache this result for some period of time. Also, ideally, the system would be smart enough to know what the nearest addresses above and below this were for which there was a CAR with authoritative mapping information. There is no mechanism for this in your proposal, as far as I can see, but I think the "Unreachable" message should contain something like: The system has no CARs which have mapping information for this address, or for addresses below it to XXX inclusive, or for addresses above it to YYY inclusive. That will save the ITRs and caching CARs from bugging any CDRs in the near future with mapping requests for nearby addresses. Perhaps this "Unreachable" reply could be renamed, because it does not imply anything about reachability of any host which might be using a mapped address - just that while an ITR enquired about this address because it assumed it might be part of the LISP system, that as far as the system knows at present, the address is not mapped by the LISP system. I am not sure at what point such a reply would be generated. I understand it should be generated when a CDR gets a request and then decides it couldn't pass it on to another CDR. (Sect 5.2 para 5.). But how did the request get that far, unless this is the very first CDR? I understand a CAR sending the request on to the one or more CDRs it connects to. Maybe that first CDR (or multiple such CARs) would find it had no entry in its EID-prefix database, so it has no parent or sibling CDR to send the request on to - so the first CDR would always be the one which generates this "Unreachable" reply. What if a CAR is authoritative for mapping the EID range: 11.0.0.0 to 11.0.255.255 but there is a whole range: 11.0.27.3 to 11.0.27.127 which currently does not map to any RLOC. There would probably be many such ranges with no current mapping. Let's say this CAR gets a request for the mapping of an EID 11.0.27.16. Not only should it reply that there is no mapping, with a cache time, but I think it should also include in the reply something to the effect: "The requested EID is part of a range 11.0.27.3 to 11.0.27.127 for which there is no mapping at present." Then the requesting ITR and its CAR(s) can cache this and stop bugging the system with further requests when it gets a packet addressed to other addresses in this range, for as long as the cache time says so. I think I broadly understand why you have this distributed network of CDRs as a kind of routing system to forward requests towards an authoritative CAR. I don't understand how you make each CAR's data become replicated somewhere else, so the system still works when the CAR is down. I was looking in your I-D to see how you implemented something like what is done with nameservers, with one being the master and others slaves, but all being authoritative to answer queries. I don't understand why you have the reply traverse all the CDRs. Why doesn't the authoritative CAR just send a response directly to the CDR and/or ITR which make the request? I don't understand why the devices which are authoritative for mapping information for a particular prefix of EID space also have to be the first point of call for requests from ITRs, other perhaps than your plan of making something like a three layer model for the whole system: Core of the orange = CDRs with various linkages and redundancies. CDRs don't cache. Their only function is to connect CARs to CARs in the shortest path manner, or with a longer path for redundancy if one or more CDRs on the shortest path fails. Skin of the orange = CARs which both hold the authoritative mapping and which act as interface points for ITRs. CARs cache the results of queries they pass on to an ITR, so if another ITR makes the same request, there is no need to send another request and response through the core. Outside the skin = ITRs, with links to one or more CARs. Would it be possible instead to have two types of devices in the "skin"?: 1 - Caching devices which one or more ITRs talk to, and which interface to the CDR core by one or more links to CDRs. 2 - Authoritative mapping devices which actually respond to the mapping requests by reference to their own database, for the addresses for which they are authoritative. These seem to be two totally unrelated functions which you have combined in the CAR. The CAR can also respond to mapping queries directly received from ITRs, but only if by chance the request concerns the small subset of the mapped address space for which this CAR is authoritative. In two places your I-D states: This case could arise when source-site is LISP-enabled (i.e., there is an ITR deployed), . . . This confirms my original understanding that all LISP variants require an ITR in the edge network of any host which will successfully send a packet to a host with EID address. When I wrote of Ivip (originally ViP) on 15 June, the key difference from LISP is that the mapped addresses (EIDs in LISP terminology) are part of advertised BGP prefixes, and so packets with destination addresses matching these prefixes will be forwarded out of edge networks which lack ITRs, ultimately to be encapsulated by one of the many Ivip ITRs in the core of the Net. This makes Ivip much more easy to incrementally deploy, since all senders will have their packets sent, whereas with LISP, only those senders in edge networks with ITRs will have their packets sent. I have asked for clarification of what LISP 1.5 involves, since Dino stated that what I was proposing was in fact LISP 1.5. So far I have had no clarification or examples. Can you give any explanation of what LISP 1.5 entails, regarding the location of ITRs inside or outside edge networks, and whether prefixes for which the system does EID-to-RLOC mapping are routed by the current BGP system? I found the following sections of your I-D confusing: Page 10: Each CAR will also have a /32 EID assigned to it from each of its configured blocks. This /32 EID is used in a Map-Request message so a replier can get the Map-Reply back to this requesting CAR in the event that no CAR has been configured with the the requested EID block. This case could arise when source-site is LISP-enabled (i.e., there is an ITR deployed), but the destination-site has not deployed LISP yet so there is no ETR. I don't understand any of this stuff about using a single IP address which is mapped by the LISP system as what is later described as the "Originating address". Forgetting about the last sentence, I don't understand why any special mechanism is required to get a message to a CAR. It has an IP address which is reachable via ordinary BGP routing, so why not send any message directly there? I don't understand why any special message technique is required if no CAR is authoritative for the EID in the request. The last sentence refers to "this", giving a possible cause for "this". I think the "this" is the "the event that no CAR has been configured with the the requested EID block." so I don't think the final sentence is trying to explain the reason for the use of a single IP address within the mapped block for sending a message to the CAR which initiated the request. Each CAR is on some fixed, or at least stable, IP address which is reachable by the ordinary BGP routing system. The block of mapped address space it is authoritative for could be split into many prefixes, including (I think) individual IP addresses, each with a different EID->RLOC mapping. Yet I thought that generally the idea with LISP was not to map individual IP addresses, but prefixes. (On the other hand, on page 3, you write that the database could hold mapping for 10 billion IP addresses - yet there are only about 3.7 billion public unicast IPv4 addresses.) If, for instance, it was desired to have a /20 block in the LISP system and the "owner" of that block (eg. the ISP or AS end-user to whom the prefix was assigned by an RIR) wanted to map this entire prefix to one ETR or another, it seems the quoted paragraph prevents this, because one address must be mapped to the authoritative CAR's IP address. Push-Add messages contain an EID-prefix, and Originator Address, a 64-bit sequence number, and a PV that records the path the message took in the CDR level (Section 6.3). Note that the Originator Address is an EID used to route a Reply back to the requesting ITR (Missing full-stop.) Pages 11 and 12 The Originator address allows a replying CDR to forward a Unreachable message (Section 6.5) back to the requesting CAR. This case arises when source-site is LISP-enabled (i.e., there is an ITR deployed), but the destination-site has not deployed LISP yet so there is no ETR. This text just seems to confirm my understanding of this IP address, but doesn't help me understand why such a mechanism is needed or desired. I skipped from 5.3 and started reading again at 6.4. Finally, when I read the title of the I-D "... Content Distribution Overlay ..." I thought this would be for a fancy use of the LISP network to efficiently transport video, sound etc. multicast or on-demand media files, which are widely referred to as "content" by those who own the pipes and packaging systems. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Jun 30 06:14: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 1I4Zyd-0002H6-It; Sat, 30 Jun 2007 06:14:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Zyc-0002H1-NN for ram@iab.org; Sat, 30 Jun 2007 06:14:50 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4ZyW-0003uR-MP for ram@iab.org; Sat, 30 Jun 2007 06:14:50 -0400 Received: (qmail 70217 invoked by uid 1007); 30 Jun 2007 10:14:43 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=TLv6kZ4ZcuclQH22VYJzQi1x7VqbfQtAlOwjePNbQD8PDyRwLuz0Rr15e3QEPFNZ ; Date: Sat, 30 Jun 2007 12:14:43 +0200 From: Gert Doering To: Robin Whittle Subject: Re: OK, shim6, if we must [Re: [RAM] Ivip (was ViP ...)] Message-ID: <20070630101443.GU69215@Space.Net> References: <20070622134152.57A4C872D7@mercury.lcs.mit.edu> <467D0C5C.6080004@firstpr.com.au> <467FCF66.6090207@zurich.ibm.com> <46807138.6090705@firstpr.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46807138.6090705@firstpr.com.au> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Brian E Carpenter , 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 Hi, On Tue, Jun 26, 2007 at 11:51:52AM +1000, Robin Whittle wrote: > portable and generally useful than IPv6 addresses, assuming the > current ban on PI IPv6 space for AS-end-users remains. As far as I know, there is no such "ban" - ARIN has been giving out IPv6 PI blocks since october last year... (The other regions are working on it, and it's likely that IPv6 PI for "AS-end-users" will show up there as well) Gert Doering -- RIPE APWG chair -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram