Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 30 May 2006 13:27:53 -0400

> I believe this discussion has gone over the edge.
> 
> The reason SPEERMINT exists is that CARRIERS want to peer.

Perhaps a fair assessment, but I suspect we all would like it to
progress beyond that.  
 
> Email is an inappropriate metaphor for carrier peering.

Perhaps but I don't think we can conclude that as yet.  There are most
definitely differences though.  I see no reason not to try to take some
of the simplicity and ubiquity of that model and trying to apply it to a
new application where it makes sense.

> 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

Yup...
 
> 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.

And most carriers will continue using the PSTN for that, IMHO.  Also
IMHO is that when those entities look to move beyond closed communities
(and today's vision of a voice application) that a speermint type of
model is more interesting.

> 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:[email-masked]]
> Sent: Saturday, May 27, 2006 5:51 AM
> To: Reinaldo Penno
> Cc: Khan, Sohel Q [CTO]; [email-masked]
> Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> On 2006/05/27 11:05, Reinaldo Penno <[email-masked]> 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 ([email-masked]) | nic.at Systems Engineer >
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 30 May 2006 19:50:40 +0200

> new application where it makes sense.

My take is that we need a system that

* allows selective peering. If we require that everybody can talk
  directly to everybody else, we don't get carrier opt-in.

* supports branching off into private interconnects.

  Ideally, all the existing private peering fabrics should fit
  into the speermint umbrella.

* scales to wide adoption, both for SIP URIs / domains as well as
  peering operators.

  Nothing in the protocol should preclude that it is used e.g.
  to get VoIP-enabled PBX systems to peer with each other.

  (Whether a carrier wants to peer with a PBX is his choice. 
  The protocol shouldn't dictate a peering policy. The contrary:
  the protocol must support all possible peering policies.)

* gives BCPs on how to do the nitty-gritty SIP details
  (caller-ID, privacy, ...)

/ol