Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Otmar Lendl <lendl@nic.at> Sat, 27 May 2006 09:51 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjvSD-0003TI-LL; Sat, 27 May 2006 05:51:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjvSC-0003TD-8y for speermint@ietf.org; Sat, 27 May 2006 05:51:28 -0400
Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjvS9-0007gV-Qx for speermint@ietf.org; Sat, 27 May 2006 05:51:28 -0400
Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 949C31A385; Sat, 27 May 2006 11:51:24 +0200 (CEST)
Date: Sat, 27 May 2006 11:51:24 +0200
From: Otmar Lendl <lendl@nic.at>
To: Reinaldo Penno <rpenno@juniper.net>
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture
Message-ID: <20060527095124.GJ1811@nic.at>
Mail-Followup-To: Otmar Lendl <lendl@nic.at>, Reinaldo Penno <rpenno@juniper.net>, Patrick Melampy <PMelampy@acmepacket.com>, "Khan, Sohel Q [CTO]" <Sohel.Q.Khan@sprint.com>, speermint@ietf.org
References: <20060527082920.GI1811@nic.at> <9BD5D7887235424FA97DFC223CAE3C2804652E6B@proton.jnpr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2804652E6B@proton.jnpr.net>
User-Agent: Mutt/1.5.6+20040907i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
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

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