RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

"Reinaldo Penno" <rpenno@juniper.net> Sat, 27 May 2006 19:12 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk4Co-0004zD-PE; Sat, 27 May 2006 15:12:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk4Co-0004z8-9n for speermint@ietf.org; Sat, 27 May 2006 15:12:10 -0400
Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk4Cm-000237-W0 for speermint@ietf.org; Sat, 27 May 2006 15:12:10 -0400
Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 27 May 2006 12:12:09 -0700
X-IronPort-AV: i="4.05,180,1146466800"; d="scan'208"; a="554064633:sNHT32104316"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture
Date: Sat, 27 May 2006 15:12:06 -0400
Message-ID: <9BD5D7887235424FA97DFC223CAE3C2804652E6C@proton.jnpr.net>
In-Reply-To: <20060527095124.GJ1811@nic.at>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Speermint] Updated Draft: SPEERMINT Peering Architecture
Thread-Index: AcaBcyq32yKsX+7rRDeNCtP6PNNXewATatMQ
From: Reinaldo Penno <rpenno@juniper.net>
To: Otmar Lendl <lendl@nic.at>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: "Khan, Sohel Q [CTO]" <Sohel.Q.Khan@sprint.com>, speermint@ietf.org
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org

So, 

Let's not think everything is new or unsolvable. People tend to spin
things like this in "new" WGs.

Of course I understand the absence of locality in the case of DNS, but
there are similar cases in IP itself (mobile IP). Also, some small ISPs
own their IP addresses and take them when move to another provider. 

Anyway, before spending much time on this we should wonder if we really
care about this problem. I believe exchanging domains names in a limited
fashion needs no change to the infrastructure whatsoever. I'm not sure
it will be needed, but it is certainly doable when the domain names are
fairly static (in terms of mobility).

Regards,

Reinaldo


> -----Original Message-----
> From: Otmar Lendl [mailto:lendl@nic.at]
> Sent: Saturday, May 27, 2006 2:51 AM
> To: Reinaldo Penno
> Cc: Patrick Melampy; Khan, Sohel Q [CTO]; speermint@ietf.org
> Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> On 2006/05/27 11:05, Reinaldo Penno <rpenno@juniper.net> wrote:
> >
> > I believe the crux of the problem was missed.
> >
> > The issue is not really the number of domains. We have today some
> > 400.000.000 million hosts on the Internet. BGP peers to do not
exchange
> > 400.000.000 million routes, they exchange in the low hundreds of
> > thousands.
> >
> > And why is that? (I guess you know where I'm getting at). That's
because
> > IP addresses lend themselves very well to hierarchical deployment,
> > compression through prefix/CIDR usage and the like. DNS names are
> > strings and hence difficult to come up with a similar scheme.
> 
> That's because IP-addresses, are, eh, addresses. Routing information.
> They are (ignoring PI space / multihoming for the moment) provider-
> dependent and if you change provider you will also get new
IP-addresses.
> 
> Domains are NAMES. Not addresses. You usually own your domain and take
> it with you if you switch email provider or web-hoster. Domains itself
> contain NO ROUTING INFORMATION. Their hierarchical structure reflects
> the delegation chain but in no way L3 or application layer routing.
> 
> I can host the webspace of my lendl.priv.at domain anywhere in the
> world, using any provider that sells webspace. The .at is no guarantee
> at all that the webserver is located in Austria.
> 
> The DNS is used to map Domain NAMES to ADDRESSES which contain routing
> information.
> 
> Any routing schema which operates on names is per definition not
> suitable for aggregation, because names are independent of network
> topology.
> 
> > I believe that if domains need to be exchanged between peers:
> >
> > 1 - Just a limited set would be exchanged and a "default layer 5
route"
> > (equivalent to a traditional default route) would be used.
> 
> This leads to suboptimal routing (e.g. consider nic.at calling
> vienna.ibm.com) and doesn't absolve the core networks from running a
> full routing table.
> 
> > 2 - Compression schemes like *.company.com, regular expressions or
the
> > like would need to be used. Having specific routes to AORs would be
> > hairy (maybe for the eventual roaming or visiting user). I wonder
how
> > LNP is solved within wireless...A specific entry for each phone?
That
> > would be crazy.
> 
> I guess the Richards on this list can give you some details on that.
But
> from all I know most LNP solutions require the exchange of at least
one
> routing record per ported number. (Other solutions do onward routing,
> there the call traverses through the donor network. Yuck.)
> 
> /ol
> --
> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint