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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 24 May 2006 10:21:52 -0400

Otmar,

I think our main difference is that I am suspecting that the policy will
be large and possibly very dynamic, thus less suitable for locating in
DNS.  Also, instead of pointing directly to a single policy document,
which seems like a one-size-fits-all periodic user poll option,; rather,
use Subscriptions where the resulting document may depend on
authentication and who is asking, and can be pushed on the schedule of
the server when the policy changes.

These are just suggestions being thrown out for discussion.  I'd like to
hear what folks think about them.

I'm also questioning how much information about SIP needs to be embedded
in other protocols like DNS, DHCP, etc. and how much might be more
cohesive if handled via SIP-based mechanisms.  Finding the right
balance, if you will.

Mike

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: Wednesday, May 24, 2006 7:44 AM
> To: Michael Hammer (mhammer)
> Cc: [email-masked]; Khan, Sohel Q [CTO]
> Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture
> 
> 
> Michael,
> 
> On 2006/05/24 02:05, "Michael Hammer (mhammer)" 
> <[email-masked]> wrote:
> > 
> > I did read one of your drafts, but had doubts about whether 
> all this 
> > policy data should be pushed in the DNS.
> 
> Well, if the policy is to big, then the DNS can contain a URL 
> which points to the large policy. See the last example in 
> draft-lendl-domain-policy-ddds.
> 
> > I was wondering whether the DNS could be used to discover:
> >  - that a particular user is served by a particular service 
> provider,
> 
> Is the user identified by E.164 number or by SIP URI?
> 
> If the latter, then my draft says:
> 
> * either the domain part of the SIP URI is the provider's ID, or
> 
> * a non-terminal NAPTR in the customer's domain points to the
>   provider's domain where the real policy is stored.
> 
> (if the former, then ENUM is used first)
> 
> > and
> >  - that service provider has a URI to which the originating SP can 
> > subscribe to get further information, and
> 
> That fits in nicely with my draft. You just need to define a 
> policy-type for this subscription information.
> 
> >  - that information says the terminating SP can support peering with
> >    = federation subset A, or 
> >    = federation subset B, or ...
> 
> Ok; if this list is long, then an external document is fine. 
> If it is very short, I prefer storing it in the DNS and skip 
> one step at call setup time.
> 
> If these are just named subsets, then the DNS need only store 
> the name of the subset and not the list of RFC and BCPs.
> 
> > I suppose that policy document could list all the RFCs you 
> support and 
> > then spend time figuring out what matches and what doesn't.  But I 
> > would wonder how well each permutation has been tested.
> 
> That problem is independent of whether you store the 
> requirement list in the DNS or retrieve it via different means.
> 
> /ol
> --
> < Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
> 

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 24 May 2006 09:46:46 -0500

I believe Mike is right on track. Overloading the DNS with application
protocol information, such as detailed policies for SIP is not what the DNS
was designed for.

Going further down this path would make the DNS a successor of the AIN!

Thanks, Henry

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 9:22 AM
To: Otmar Lendl
Cc: Khan, Sohel Q [CTO]; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Otmar,

Mike

---

From: "Patrick Melampy" <[email-masked]>
Date: Wed, 24 May 2006 11:17:01 -0400

Subscriptions have other beneficial attributes -- as they can work across
network boundaries and have context. Subscribe/Notify can deliver a policy
that corresponds to a reverse flow of SIP traffic. Plus the Notification can
provide near real time changes. Also very contextual data can be included in
the notification -- providing a nice mechanism for automatic congestion
control.

I like DNS providing LOCATION only, and I like the notion of all other
attributes that have a contextual base to be delivered in a contextual way.
Plus the actually XML policy document could be the same as your proposing --
but have additional information that is related to the exact subscription
(proxy to proxy) relationship.

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 10:22 AM
To: Otmar Lendl
Cc: Khan, Sohel Q [CTO]; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Otmar,

Mike

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 24 May 2006 23:04:39 +0200

Michael,

> the server when the policy changes.

My guess is that the size of the policy will vary a great deal.

We don't know yet what the market will establish in the future.

That's why I used URIs are policy element identifiers. This gives
us a wide range of options:

* Simple IDs which refer to offline established policies. (= federation
  names)

* References to standards

* References to documents describing a complex policy

and (if you want a dynamic protocol)

* the location and connection parameters for any routing /
  policy-exchange / ... protocol.

As an example (and not meant as a real proposal): let's assume
that the destination requires the use of the Open Settlement Protocol.
We could standardize an URI scheme for that, e.g. "osp://hostname:port/"
and a suitable policy-record could thus be

	NAPTR 10 10 "u" "D2P+SIP:osp" "!.*!osp://hostname:port/! .

You can do the same for your subscription model.

----

As for why you don't want to do all that with SIP, I refer to
http://www1.ietf.org/mail-archive/web/speermint/current/msg00218.html

> hear what folks think about them.

So do I.

> cohesive if handled via SIP-based mechanisms.  Finding the right

Indeed. My problem with a pure SIP solution is the following:
Assuming that members of some federations will opt to move their SIP
ingress points to private IP networks and/or firewall them heavily
I see a severe chicken and egg problem if the discovery of the 
correct SIP ingress point is done by a SIP exchange.

/ol

---

From: David Meyer <[email-masked]>
Date: Thu, 25 May 2006 07:53:09 -0700

> Going further down this path would make the DNS a successor of the AIN!

	Yes, and in addition, add the somewhat ("somewhat")
	ironic observation that while folks want to use the DNS
	for just about everything under the sun due to its
	reliability and reach, undisciplined overloading of the
	DNS will very likely destroy just that set of properties
	that people find attractive about it.

	--dmm

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 25 May 2006 21:36:12 +0200

Michael,

> hear what folks think about them.

Re-reading your mail I found one aspect I'd like to highlight:

If you talk about a "subscription" of some sort, I assume that
you mean that the originating network kind of registeres at the
destination network and receives updates about the state of this peering
relationship. In a way, this sound similar to what BGP does.

Have I interpreted this correctly? If not, please ignore the rest of this mail.

The reason we decided NOT go this route is the following:

Once you require that the border element of a SIP operator
establishes a permanent session with the ingress elements
of its peer before any calls can traverse this peering, then
you almost require the manual configuration of this peering.

That's fine if you take the peering model of BGP as reference.
Layer 3 peering requires a physical connection (except at exchange
points), peering is thus always an explicit and human decision and thus
the manual BGP configuration is no issue.

Peering at the SIP layer is different: you usually don't need build any
extra physical connection. You can instantly peer with all other SIP
services connected to the Internet once you're connected to it. The
range of peering partners thus isn't limited to the ones to which you
build a direct physical link. The set of potential peering partners is
huge and reaching them does not involve any additional lower layer work.

In the spirit of the Internet end-to-end model, I consider it thus
essential to design a system with which all these VoIP operators
can in effect establish peering relationships with each other.
I won't force ubiquitous peering on all VSPs, but the system should
make it possible.

As an example, consider the following scenario:

  A set of VoIP service providers form an association and exchange traffic
  via the public Internet using SIP with the TCP/TLS transport protocol
  for confidentiality and peer authenticity by using X.509 certificates
  signed by the association's certificate authority.

If a new operator joins such a club, what needs to happen?

With domain policies the following:

* the new guy get's his TLS cert signed
* the new guy configures his ingress points to allow connections
  via TLS and a correct cert
* he announces his membership in that federation by adding a NAPTR
  record to his domain

That gives us O(n) scaling.

Imagine what needs to happen if you have to configure BGP-like links:

* the new guy has to estabish links to all existing members
* and the reverse: all existing members have to be told about this
  new guy and have to configure their side of the peering link.

This has complexity of O(n*n).

(or do you have something similar like the BGP route-reflectors in mind?)

---------------

If some group of operators want pre-configured links (and thus O(n*n)
complexity), fine, let them do that within their federation. 
My proposal doesn't rule that out. 

On the other hand I think we should be extremely careful not to build
something with precludes setups with far better scaling properties.

/ol

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 25 May 2006 16:35:25 -0400

Joining in....

I believe your proposal could make sense in some settlement free
(business or otherwise) environment like those VoIP peering points in
Europe. I could also take your proposal even further and argue that
everybody will have a domain name and SIP server at their homes and peer
directly over TLS with the domain to which the call is destined. This
will create a O(n^2) where n is quite large.

My guess is that in reality many ISPs, MSOs and Carries will peer at
specific peering points with well defined rules. The big players will
provide peering service for the small ones being them enterprise or
otherwise. This would reduce the O(n^2) that you are so worried about. 

So, good news, it is already like this. Global carriers already provide
the link and VoIP services for big enterprises. Smaller ISP use big ones
for transit, etc, etc 

I bet there will also be tons of consolidation amongst pure VSPs and
many of them will just go chapter 11 when competing with big carriers.
But now we are in the VSP feeding frenzy...

I also do not follow your example below. It seems you are bundling
several control aspect functions. In the BGP model you establish a TCP
connection with each peer and exchange routing tables. In the TLS model
you also establish one connection with each peer to exchange SIP control
traffic. How's that different? What do you call links?

The only difference between the models (DNS vs. subscription) that you
could argue is what routing people call membership and discovery. What
you say is that discovery and membership is faster with a DNS model. 

I would argue that in all cases DNS could be used for location (apart
from manual configuration) and in non ad-hoc peering scenarios
subscription provides a quasi instantaneous notification when a peering
policy changes, it does not involve any third party server, and can
carry variable amounts of data, and already possess all security
features existing in SIP. 

As for the subscription-reflector, it is an idea that comes to mind when
hundreds of VSP need to peer. I do not think a scalable SIP server
handling possibly >> 200caps (my guess number) will have any problems
handling a few dozens subscriptions. 

Regards,

Reinaldo

> Sent: Thursday, May 25, 2006 12:36 PM
> Have I interpreted this correctly? If not, please ignore the rest of
this
> mail.

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 26 May 2006 12:49:32 +0200

> Joining in....

Welcome.

> will create a O(n^2) where n is quite large.

Indeed. I think we should not design something that does not work in that setting.  

> specific peering points with well defined rules. 

I expect that to happen as well. I consider such a peering point incl.
its rules as a prime example of a federation. The domain policy DDDS
is thus very well suited to tell originating networks at which
peering exchanges the destination network is present.

> The big players will

Yes, I can imagine the big players want to do that. On the other hand, the
small ones and the enterprises want to avoid them for as many calls
as possible.

> the link and VoIP services for big enterprises. Smaller ISP use big ones

That's the classic hierarchical model of communication.

This makes a lot of sense for anything which requires a physical
connection, like e.g. L3 traffic.

I'm not so sure whether that's the only model if you talk about
application layer stuff. Consider e.g. email. There you had 
X.400 with its hierarchical model and SMTP with its flat
"everybody can talk to everybody" model. 

Which won the quest for world dominance?

In the early days of the commercial Internet, a lot of enterprises
used their ISPs as mail relay. (That was an unlimted source of
joy for me as the postmaster of an ISP) 

These days almost all enterprise <-> enterprise email will not
touch the mailserver of an ISP.

Ditto for mails between small ISPs: the layer 3 packets will get handled
by backbone operators, but at the SMTP layer they are not involved at all.

The same is possible with SIP. Small operators and enterprises
can choose to route all their traffic via the SIP servers of
bigger operators, or they can choose to bypass those.

I can't imagine that the IETF will endorse a solution which
takes away that choice.

> But now we are in the VSP feeding frenzy...

The competition between VSPs will look tame compared to what will happen
when the carriers have to compete with their own customers.

> traffic. How's that different? What do you call links?

The difference is in the setup. 

A BGP connection needs manual configuration on both sides.
The set of communication endpoints (in this case, layer3) that
is reachable via that peering is negotiated *within* that connection.

For SIP/TLS, reachability information is not exchanged via the
SIP connection. The DNS is used for that.

The TLS connection is dynamically established at the first call to the
destination domain based on the information in the destination's domain. 
(RFC3263 NATPR, SRV + A records)

TLS is used for authentication and security and SIP is just the means to
complete the call and is not a routing protocol.

> you say is that discovery and membership is faster with a DNS model. 

I'm not sure if I can follow you here.

> features existing in SIP. 

Do I read this correctly that you want a SIP-based routing architecture
where reachability information between networks are exchanged via
SIP messages?

In other words, something like BGP, but instead of L3 routes (connected
neworks as identified by CIDR prefixes) this protocol talks about
SIP URIs (or SIP domains)?

In that case RFC3263 "Locating SIP Servers" (which is purely DNS-based)
would be replaced by this SIP-based routing protocol?

/ol

---

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 26 May 2006 08:03:14 -0400

> Sent: Friday, May 26, 2006 3:50 AM
> To: Reinaldo Penno
> Cc: Michael Hammer (mhammer); Khan, Sohel Q [CTO]; [email-masked]
> Indeed. I think we should not design something that does not work in
that
> setting.
> SIP connection. 
>The DNS is used for that.
[[Reinaldo]] 

Okay, this is where I believe you are confusing things.

DNS is used for _location_ (thus the name of the RFC "Locating SIP
Servers"), _not reachability_. Location is _quite_ different than
reachability. 

The only device that can attest reachability to the SIP proxy's IP
address provided by a DNS server in a response is a router or a device
with similar properties.

> (RFC3263 NATPR, SRV + A records)
[[Reinaldo]] 

Sure.

> where reachability information between networks are exchanged via

Reachability or location?

> would be replaced by this SIP-based routing protocol
> 
> /ol
> --

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 26 May 2006 15:35:46 +0200

> attributes that have a contextual base to be delivered in a contextual way.

I think I can see your point.

I still have a serious problem regarding how to bootstrap such a
system as

* Carriers seem to hate to expose their SIP ingress elements to the open
  Internet. They firewall, use private address spaces (e.g. GRX) or
  otherwise block incoming SIP calls before they reach the SIP stack.

* we want to avoid a mandatory bilateral configuration of peerings.
  
Could you sketch how a dynamic peering discovery could work with a
SIP subscription model?

/ol

---

From: "Patrick Melampy" <[email-masked]>
Date: Fri, 26 May 2006 12:48:41 -0400

I suppose like in any distributed routing protocol, there are some chicken
an egg issues. But consider the following.

PREREQUISITES:
1.) You know the destination DOMAIN from either ENUM or other means.

Consider 3 carriers A, B, C

A subscribes to B for a list of reachable domains.
B notifies A that both B and C are reachable.

B subscribes to A for a list of reachable domains.
A notifies B that A is reachable

C subscribes to B for a list of reachable domains.
B notifies C that both A and B are reachable.

B subscribes to C for a list of reachable domains.
C notifies B that C is reachable.

Now domain A can send SIP based communications for destinations in B or C
domains.

Likewise, C can send SIP based communications for destinations in A or B.

If C were to become unreachable -- B would notify A.

This technique is very similar to TRIP, only its for DOMAINS and not partial
E.164 numbers.

These SUBSCRIBE/NOTIFY sequences could occur between adjacent proxies --
proxies that are dedicated edge proxies for routing between these carriers.
The actual policies in force could be different at each and every adjacent
proxy location.

Obviously, the data set could get large, as the list of domains can be
really big. There are some possibilities here...

1.) Have notification point to a published document, and the document lists
all of the relevant reachability in real time. Thus any change to the
document would generate a NOTIFICATION.

2.) User partial domains, broken up by the "dots". This may allow some
wildcarding to reduce the number of domains. For instance, a carrier like
Verizon may have many 100's of domains attached to it, and version is
willing to route and manage SIP traffic to any of them. The NOTIFY could
contain something like: Verizon.com or *.verizon.com to indicate that any
domain in Verizon is reachable.

An issue does arise when thinking about PSTN numbers. Since many carriers
will have an interface to the PSTN, these are not owned by any domain. Thus
we may need to expand support for PSTN reachable numbers somehow? One idea
would be to also perform subscribe and notify for partial E.164 numbers
similar to how it was proposed in the TRIP protocol. 

This technique may work -- and fit nicely into an existing protocol. All we
would need to do is define the data models (XML?) and or documents for
exchanging.

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Friday, May 26, 2006 9:36 AM
To: Patrick Melampy
Cc: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; [email-masked]
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

  

/ol

---

From: "Francois D. Menard" <[email-masked]>
Date: Fri, 26 May 2006 21:25:52 -0400

I would motion that SPEERMINT only deals with E.164 numbers that are
acessible across a SIP NNI. Any E.164 numbers that are also reacheable over
TDM is out of scope.

F.

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]]
Sent: Friday, May 26, 2006 9:36 AM
To: Patrick Melampy
Cc: 'Michael Hammer (mhammer)'; 'Khan, Sohel Q [CTO]'; [email-masked]
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

On 2006/05/24 17:05, Patrick Melampy <[email-masked]> wrote:
> Subscriptions have other beneficial attributes -- as they can work 
> across network boundaries and have context. Subscribe/Notify can 
> deliver a policy that corresponds to a reverse flow of SIP traffic. 
> Plus the Notification
can
> provide near real time changes. Also very contextual data can be 
> included
in
> the notification -- providing a nice mechanism for automatic 
> congestion control.
> 

I still have a serious problem regarding how to bootstrap such a system as

  
Could you sketch how a dynamic peering discovery could work with a SIP
subscription model?

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Sat, 27 May 2006 10:29:20 +0200

> 1.) You know the destination DOMAIN from either ENUM or other means.

[...]
> This technique is very similar to TRIP, only its for DOMAINS and not partial

[...]

> really big. There are some possibilities here...

Let's do a quick estimate on the number of domains involved:

Right now, operators usually give customers URIs of the form
<number>@<providerdomain>. As long as this is the state of affairs,
we're fine as the number of providers is quite finite (a few
thousands, perhaps).

This is like the state of affairs with respect to email, anno 1990.
Back then customers started to notice that if they use their own domain
for email, then they can switch providers without having to change
their email address. Thus a *lot* of people opted to use their
own domain for email.

My guess is that the same will happen to SIP. Once customers print
their SIP uris on business cards, they will want to use their own
domains. If providers won't support that feature then I suspect that
the regulators will step in and mandate an URI portability solution
just as they did in the PSTN with respect to numbers from number blocks.
(This could get really nasty protocol-wise, so I guess using customer-
owned domains is the far better and likelier solution to the porting
question.)

So: Anything we come up with here in SPEERMINT needs to cope with a
scenario where the use of customer domains in SIP URIs is just as
widespread as it is for email. 

How many domains are used for email? That's hard to say. There are
about 60 million gTLD domains and probably more than 20 ccTLD ones.
Assuming that only a tenth of that is used for email we're at
8 million domains. Given the exponential growth any system which
doesn't scale to at least 10 million domains will be obsolete before
the ink is dry on the RFC.

So what happens if we do some sort of BGP or TRIP with domains?

Let's say we need at least 100 bytes of state information per domain.
That makes a full routing table 1 GB worth of data. That also means
that a new border element needs to exchange that amount of data
with its peers before it has learned the current state of the
routing table.

That is some serious amount of data.

> document would generate a NOTIFICATION.

+ a download of up to 1 GB per peer.

> domain in Verizon is reachable.

That's helpful if a provider uses subdomains for internal purposes,
but that won't help you with customer owned domains.

> would need to do is define the data models (XML?) and or documents for

I think this technique can work -- if you add an aggregation step
before the routing scheme. 

Take another look at BGP: there you have the concept of an 
Autonomous System and not only that of prefixes. Maybe you need
something similar.

One approach to cope with hosted SIP domains could be to use the 
hostnames as found in SRV records. E.g. for settings like

_sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com

run the routing algorithm on "sip.provider.com" instead
of "customer.domain".

Another option is to store some AS-equivalent in the customer domain
and have the routing algorithm operate on that. In my domain-policy
framework this could be expressed e.g. like

customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id" 
	"!.*!urn:ietf:speermint:RID:1042!" .

stating that this domain can be reached using the Speermint routing 
logic by using the learned route to RoutingID 1042.

Or, even better, use non-terminals, and thus refer to the ingress
policy stored in the provider's domain:

customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com

provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id" 
	"!.*!urn:ietf:speermint:RID:1042!" .

(+ whatever other facts provider.com wants to announce about his
reachability.)

This combination of our ideas can indeed work and scale to an
unlimited number of customer-owned domains.

/ol

---

From: "Reinaldo Penno" <[email-masked]>
Date: Sat, 27 May 2006 05:04:28 -0400

Hello,

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. 

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.

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.

3 - Some new scheme that will make somebody rich....until then..

I believe subscriptions would be used to exchange mostly "cost" and
policy information and some domains. I use cost here in the layer 3
sense (number of calls, jitter, whatever). Cost would be an abstract
value or a more specific one (up to the administrator).
 
Regards,

Reinaldo

> Sent: Saturday, May 27, 2006 1:29 AM
> To: Patrick Melampy
> Cc: 'Khan, Sohel Q [CTO]'; [email-masked]
> > 1.) Have notification point to a published document, and the
document
> lists
> > contain something like: Verizon.com or *.verizon.com to indicate
that
> any
> > This technique may work -- and fit nicely into an existing protocol.
All
> we

---

From: Otmar Lendl <[email-masked]>
Date: Sat, 27 May 2006 11:51:24 +0200

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

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

> LNP is solved within wireless...A specific entry for each phone? That

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

---

From: Duane <[email-masked]>
Date: Sat, 27 May 2006 08:18:35 -0400

> the delegation chain but in no way L3 or application layer routing.

Ummm does DNS servers (like pdns which has a geo module) that return 
info on closest server based on your IP count?

-- 

Best regards,
  Duane

---

From: Otmar Lendl <[email-masked]>
Date: Sat, 27 May 2006 14:56:15 +0200

> info on closest server based on your IP count?

No, as the domain (we're talking normal gTLD or ccTLD) name itself
does not contain the topology information. 

Only after you plug that name into a mapping protocol (in this
case DNS) you get topology-relevant information.

Example:

    www.google.com is a name. In itself it contains no information 
    where the server is located. 

    If I make a lookup from here in Austria, I get

    www.google.com is an alias for www.l.google.com.
    www.l.google.com has address 66.249.85.104
    www.l.google.com has address 66.249.85.99

    The two addresses (if we ignore IP anycasting)
    define where on the Internet the server is located.

    Asking a traceroute server in australia I get

    www.google.com canonical name = www.l.google.com. 
    Name: www.l.google.com 
    Address: 66.102.7.99 
    Name: www.l.google.com 
    Address: 66.102.7.147 
    Name: www.l.google.com 
    Address: 66.102.7.104 

/ol

---

From: "Reinaldo Penno" <[email-masked]>
Date: Sat, 27 May 2006 15:12:06 -0400

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

> Sent: Saturday, May 27, 2006 2:51 AM
> To: Reinaldo Penno
> Cc: Patrick Melampy; Khan, Sohel Q [CTO]; [email-masked]

---

From: "Richard Shockey" <[email-masked]>
Date: Sun, 28 May 2006 14:09:56 -0400

Yes Henry ..but whether we like or not the DNS or at least the technology of
DNS is becoming the defacto number translation database of choice and as
such heralds the end of SS7.

Queried or cached it makes no difference.

> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Wednesday, May 24, 2006 10:47 AM
> To: 'Michael Hammer (mhammer)'; 'Otmar Lendl'

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 29 May 2006 19:16:57 -0500

> Queried or cached it makes no difference.

The authors of this paper represent those who think there is a big
difference. Reasons include DNS caching conflicts with changing IP
addresses, security, etc. 

http://www.cs.cornell.edu/people/egs/papers/codons-sigcomm.pdf 

Fee free to dismiss yours humbly, I don't mind, but addressing the arguments
in the paper would be more convincing. 

It would be interesting to learn why the 20 year old DNS 'as is' is
considered to be good enough for eternity and any successor technology does
not even merit a read, let alone reconsidering business evolution plans
based on 1986 technology. Reminds us of SS7 indeed...

So what are counter-arguments to those presented in the paper on the
Cooperative Domain Name System? 

Thanks, Henry

---

From: Duane <[email-masked]>
Date: Mon, 29 May 2006 20:59:38 -0400

> addresses, security, etc. 

We drop the TTL to between 1 minute and 10 depending on how static the 
number block is, so caching issues can easily be dealt with in most 
instances (not including broken configuration on caching servers).

> based on 1986 technology. Reminds us of SS7 indeed...

I think this is in the ball park of trying to replace email, and these 
technologies are ingrained into how people think operate rather then 
learning new technologies, not to mention they just work (if it ain't 
broke?)...

This kind of reminds me of an article I was reading some time ago about 
what it takes for a new technology to actually make it (kind of like 
HDD/DVD/CD etc verses something like the zip disk/jazz drive)... The 
authors conclusion was it had to be a factor of 10 better then the old 
technology or people just didn't bother...

-- 

Best regards,
  Duane

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 30 May 2006 08:17:09 -0400

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:[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

/ol