RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

I believe this discussion has gone over the edge.

The reason SPEERMINT exists is that CARRIERS want to peer.

Email is an inappropriate metaphor for carrier peering.
Email and normal SIP routing are approximately the same:
	Generally speaking, a domain accepts mail (calls) from any domain
	The mail (call) is marked by the sender with the domain of the
recipient
	Mail (calls) is (are) exchanged over the open Internet
	You find the mail (sip) server by looking at the DNS entry 
		for the domain

I expect that some day, that IS the way we will do calls, but right now,
carriers get paid to make calls work, and they want closed communities.
At any point, a carrier or any other domain can just take a SIP URI and
route it with normal RFC3261 routing to its destination URI.  It's probably
not the originating domain that cares, it's the terminating domain.

As Richard points out rather frequently, SPEERMINT does not deal with
E.164s, it deals with SIP URIs.  They have the domain, but in SPEERMINT, we
need something other than an SRV entry for the domain to be able to
terminate it.

Some day, we'll just do domain to domain calls, just like email, but that is
not what SPEERMINT deals with.

Brian

-----Original Message-----
From: Otmar Lendl [mailto:lendl@nic.at] 
Sent: Saturday, May 27, 2006 5:51 AM
To: Reinaldo Penno
Cc: 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

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