Subject: [Speermint] Multihop routing

From: Otmar Lendl <[email-masked]>
Date: Fri, 23 Feb 2007 17:57:49 +0100

On 2007/02/20 22:02, "Livingood, Jason" <[email-masked]> wrote:
> 
> If you have some suggestions on how multi-hop routing and routing based
> on numbers should occur that is not fully addressed elsewhere, I
> encourage you to start up some threads on the mailing list here.  I
> suspect other folks may be experiencing the same issues you cite, but
> the only way to tell is to start up discussion.  

The issue is rather simple:

One of the basic premises of SIP is the famous end-to-end principle:

  The destination uses the DNS to publish the IP addresses of
  its ingress elements.

  On the sender side, the call may be handed to one outbound-
  proxy, which is independent of the destination of the call.

  Between that outbound proxy and the ingress proxy all
  routing is pure layer3: no further SIP device is involved.

  To achieve worldwide reachability, the ingress elements of the
  destination must accept calls from any source on the Internet.

Almost all of the scenarios as documented by current drafts
in the speermint WG deviate from this model, they assume:

* A VSP wants to control with whom he peers

* Peering is done over private networks

* Non-public databases are used to route calls over such
  interconnection networks.

* In order to complete calls to any valid destination TN/URI,
  VSPs have to rely on the PSTN (as fall-back) and transit
  service providers.

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

What does that mean for a typical call? The SIP architecture
assumes something like this:

   /---\  /---\    ----------------  /---\  /---\
   |UAC|--|VSP|-- / pure layer 3 / --|VSP|--|UAC|
   \---/  \---/  ----------------    \---/  \---/

whereas the speermint requirements lead to diagrams like this:

   /---\  /---\  /-----\  /-----\   /---\  /---\
   |UAC|--|VSP|--|tVSP1|--|tVSP2|---|VSP|--|UAC|
   \---/  \---/  \-----/  \-----/   \---/  \---/

(with transit VSPs involved at the SIP layer).

Real life is way more complicated: There are a lot of VSPs which
interconnect to each other over private links, peering fabrics, or even
over the Internet.

If we start to draw that as a graph with VSPs as nodes and peerings as
edges, than we have a text-book example of a generic network. A call
from one side of the network to the other needs to find a path through
this graph. Each step is a SIP peering, which could involve any number
of layer3 hops between the SIP proxies.

The SIP mechanisms are fine _within_ each step: The microcosmos of
a peering fabric looks like the Internet as envisioned by the SIP
standard: full L3 connectivity between participants plus a shared DNS
tree including an ENUM branch.

What SIP can't do is routing between these mini-Internets. There are no
mechnisms to choose the best of a multitude of possible paths through
the network of VSPs.

That wasn't part of the design, as this is a radical departure from the
sacred end to end principle.

There are just two possible choices:

* Convince the VSPs to adopt the end to end priciple and open
  up their networks (and forget about termination fees as a side
  effect), or

* Be prepared to design a routing protocol on the SIP layer.

(Compromises here don't look feasible to me, something like
http://en.wikipedia.org/wiki/Open_settlement_protocol might
be used to decouple the trust relations from connectivity, but
I doubt that would be enough.)

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

Here is an analogy from a bit lower on the protocol stack:

If you want to send an IP packet over a switched ethernet
infrastructure, you just need one ARP request to map IP address to MAC
address which is used to send the packet on its way.  Both sides don't
care how many L2 switches are involved, and what version of the spanning
tree protocol they use to build their mac-based forwarding table.

As long as the whole network is a single broadcast domain, this works
fine. If you have just a few other LANs you might employ proxy ARP to
bridge these together.

This band-aid is clearly insufficient once the single L2 network is
split up in multiple networks connected via L3 routers. ARP is still
fine within each segment, but a L3 routing protocol is needed to
maintain connectivity on the IP layer.

Substitute as follows:

IP layer	-> SIP layer
IP address	-> SIP URI  (or Telephone number)
MAC address	-> IP address
spanning tree	-> BGP
broadcast domain-> IP layer connectivity
ARP		-> DNS lookup to map domain to IP address
proxy-ARP	-> announcing non-local destinations in a
		   fabric's DNS

and thus

L3 routing	-> SIP routing

Just as it would be ridiculous to propose to use proxy-ARP to solve the
worldwide IP routing problem, I'd be very sceptical that one can solve
the VoIP routing problem with minor tweaks of the RFC3263 rules.

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

All this doesn't mean we don't need to talk about how individual
peering fabrics (these mini-Internets) work and what BCPs with
regards to SIP we need to come up with for them.

But all that will never ever be enough to replace the PSTN
as THE global voice network with a SIP-based alternative.

Comments?

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

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

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 23 Feb 2007 12:34:17 -0600

Hi, Otmar,

Nice summary.

Thanks,

Spencer

> On 2007/02/20 22:02, "Livingood, Jason" 
> <[email-masked]> wrote:
>>

---

From: Andrew Newton <[email-masked]>
Date: Fri, 23 Feb 2007 14:19:55 -0500

This sounds like RFC 3219.

-andy

---

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 23 Feb 2007 15:30:31 -0500

Reading Otmar's federation draft I had the impression that many
practical problems related to multi-hop SIP routing were addresed there.

IMO a SIP layer routing protocol have a very low chance (zero?) of not
only becoming a WG item but being implemented as well. 

This begs the question on what is going on with the federation drafts?
They are not WG items, but they are referred byt other WG docs
explicitly. Everytbody talks about it but in San Diego it seemed we did
not get enough raised hands to make it a WG item....

So?

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]] 
> Sent: Friday, February 23, 2007 11:20 AM
> To: Otmar Lendl
> Cc: [email-masked]
> Subject: Re: [Speermint] Multihop routing
> 
> >> If you have some suggestions on how multi-hop routing and routing 
> >> based on numbers should occur that is not fully addressed 
> elsewhere, 
> >> I encourage you to start up some threads on the mailing 
> list here.  I 
> > Almost all of the scenarios as documented by current drafts in the 
> > speermint WG deviate from this model, they assume:
> >
> > What does that mean for a typical call? The SIP 
> architecture assumes 
> > something like this:
> >
> >
> > interconnect to each other over private links, peering fabrics, or 
> > even over the Internet.
> >
> > The SIP mechanisms are fine _within_ each step: The 
> microcosmos of a 
> > peering fabric looks like the Internet as envisioned by the SIP
> > What SIP can't do is routing between these mini-Internets. 
> There are 
> > no mechnisms to choose the best of a multitude of possible paths 
> > through the network of VSPs.
> >
> > That wasn't part of the design, as this is a radical departure from 
> > the sacred end to end principle.
> >
> be used to 
> > decouple the trust relations from connectivity, but I doubt 
> that would 
> > be enough.)
> >
> > ------------
> >
> > care how many L2 switches are involved, and what version of the 
> > spanning tree protocol they use to build their mac-based forwarding 
> > table.
> >
> > Just as it would be ridiculous to propose to use proxy-ARP to solve 
> > the worldwide IP routing problem, I'd be very sceptical 
> that one can 
> > solve the VoIP routing problem with minor tweaks of the 
> RFC3263 rules.
> >
> > ------------
> >
> > peering fabrics (these mini-Internets) work and what BCPs 
> with regards 
> > to SIP we need to come up with for them.
> >
> > But all that will never ever be enough to replace the PSTN as THE 
> > global voice network with a SIP-based alternative.
> >
> > Comments?
> >
> > /ol
> > --

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 23 Feb 2007 15:43:48 -0500

The federation work in definitely getting put into our work here.  That
starts with federation use cases going into the consolidated use cases
and will result in federation requirements, an architecture that
supports federations, etc.  

As to a SIP layer routing protocol, that is likely to be out of scope
here.  BUT, that is not to say that we cannot document what our needs
are and then refer that work to one of the other RAI WGs for
resolution... 

Jason 

> From: Reinaldo Penno [mailto:[email-masked]] 
> Sent: Friday, February 23, 2007 3:31 PM
> To: Andrew Newton; Otmar Lendl
> Cc: [email-masked]
> Subject: RE: [Speermint] Multihop routing
> 
> Reading Otmar's federation draft I had the impression that 
> many practical problems related to multi-hop SIP routing were 
> addresed there.
> 
> IMO a SIP layer routing protocol have a very low chance 
> (zero?) of not only becoming a WG item but being implemented as well. 
> 
> They are not WG items, but they are referred byt other WG 
> docs explicitly. Everytbody talks about it but in San Diego 
> it seemed we did not get enough raised hands to make it a WG item....
> 
> So?
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 23 Feb 2007 16:03:21 -0500

> The issue is rather simple:
<snip>
> microcosmos of a peering fabric looks like the Internet as 
> envisioned by the SIP
> standard: full L3 connectivity between participants plus a 
> shared DNS tree including an ENUM branch.
> 
> There are no mechnisms to choose the best of a multitude of 
> possible paths through the network of VSPs.

I think now you are getting to the heart of your concerns...

<snip>
>   up their networks (and forget about termination fees as a side

Our collective chances of achieving this by force of standards is zero.

But we are laying out a path to go from direct -> federated -> open.  
The market will choose its own pace.

> be used to decouple the trust relations from connectivity, 
> but I doubt that would be enough.)

I think it is time to call in some gurus from SIP WGs to start to
comment...
 
JL

---

From: Michael Haberler <[email-masked]>
Date: Sat, 24 Feb 2007 03:09:15 +0100

> This sounds like RFC 3219.

yes - modulo protocol economics.

if telephone numbers or prefixes are deemed a good choice as the  
primary routing key and full transitivity of the routing matrix is a  
requirement, then indeed TRIP would be a solution.

our assumptions behind the Lendl federation/discovery I-D's were:

a) numbers/prefixes are needed for endpoint and/or ingress resolution  
BUT they are bad choice for a routing key long term. "Private ENUM  
club equals federation" is a short term fix for those buying into the  
long-term downside.
b) long term the average transit path length will go down,  
approaching end-to-end asymptotically.
c) full transitivity is not a requirement since the voice transit  
business models don't scale to arbitrary path length in the first  
place, likely less so as time progresses - note this is different  
from the total connectivity promise delivered by BGP (get everywhere  
cheapest according to some cost criteria)

which is why we assumed an incremental, on demand target discovery  
model gets you most of the TRIP benefits at a fraction of the cost  
and without number legacies. Improve it by cache priming for a near- 
optimum routing and you cover lots of scenarios - like enterprise to  
enterprise.

that's why I think the TRIP economics doesnt fly: important problem,  
total solution, wrong primary key to solution, adoption cost not  
justifiable WRT benefits.

-Michael

>>> based
>> even
>> spanning

---

From: "Creighton, Tom" <[email-masked]>
Date: Mon, 26 Feb 2007 09:51:48 -0500

I do not agree that TRIP is a viable option for the countries that
support number portability.  It would be the equivalent to trying to
aggregate your IP routes in BGP if you allowed your customers to keep
their IP addresses when they sign up for or cancel their Internet
service.  Simply put, it will not scale.

Tom

> From: Michael Haberler [mailto:[email-masked]]
> Sent: Friday, February 23, 2007 21:09
> To: Andrew Newton
> Cc: [email-masked]; Otmar Lendl

---

From: "PFAUTZ, PENN L, TCORP" <[email-masked]>
Date: Mon, 26 Feb 2007 10:02:39 -0500

Amen! The only way TRIP can work under number portability is if we keep
the whole TDM-based NP routing structure around forever. You must
exchange prefix (NPA-NXX) reachability in TRIP, do an LNP query on each
call to discover the routing number (LRN in the US) and then route based
on the NPA-NXX of the routing number. 

Penn Pfautz
AT&T Global Access Management
+1-732-420-4962

-----Original Message-----
From: Creighton, Tom [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 9:52 AM
To: Michael Haberler; Andrew Newton
Cc: [email-masked]; Otmar Lendl
Subject: RE: [Speermint] Multihop routing

Tom

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 26 Feb 2007 16:46:52 +0100

> This sounds like RFC 3219.

Yes, TRIP tries to address the same issue, at least for TN based routing.

Actually, this is a good question for the carriers and vendors here on
this list: Why hasn't TRIP seen any adoption?

Is it just the scaling issues with telephone numbers as the keys?

Or was this a case where neither operators nor vendors made the first
step to adoption? Has anybody done an implementation at all?

/ol

---

From: Andrew Newton <[email-masked]>
Date: Mon, 26 Feb 2007 10:52:43 -0500

> service.  Simply put, it will not scale.

That is an interesting observation.  But it begs the question, how  
will any multi-hop routing work with number portability then?

I also wonder if this is a theoretical problem?  While I understand  
the goal, it isn't a problem we experience today.  That's not to say  
that nobody does multi-hop routing today, but that it is usually  
achieved by VSPs in very entity-specific way and not in need of inter- 
domain coordination.

-andy

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 26 Feb 2007 17:42:30 +0100

> will any multi-hop routing work with number portability then?

By adding a mapping operation in front of the routing protocol.

Consider email: it would be pointless to create a routing protocol for
email which is keyed on domains. The number of domains is huge and there
is no way to aggregate these. The solution there is to use the DNS to
map domains to the IP-addresses of the mail-servers.  These can be
aggregated and are suitable as keys for routing protocols.

We probably need to do the same for this problem:

* Use a directory lookup to map TNs to other identifiers which
  are better suited for a routing protocol.

* Build a routing protocol on top of these identifiers.

--------

My sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
  &nbsp;&nbsp;15 minutes<BR>&nbsp;&nbsp; </DIV>
  <DIV>&nbsp;</DIV>
  <DIV></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D932220415-26022007><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C759C5.14D4FD3D--

--===============0925080835==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============0925080835==--

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 26 Feb 2007 17:42:30 +0100

--------

My proposals (draft-lendl-domain-policy-ddds-02 +
draft-lendl-speermint-federations-03) propose to use

- I-ENUM to map TN to SIP URIs

- a DDDS application to map the domain part of those URIs to federation
  identifiers

- Route based on the federation IDs. (in the best case: just route via
  a shared federation)

You could save one step by storing the federation IDs directly in
I-ENUM, but you loose the possibility to do URI-based calls with the
same framework.

> achieved by VSPs in very entity-specific way and not in need of inter- 

Right now, we're seeing a lot of ad-hoc peering with hand-spun route
advertisements. Whatever transit traffic is currently passed via SIP,
the routing seems to be mainly done via manual, static routes.

If we ever want to get rid of the PSTN as the "default route" to be
uses when the destination isn't a peer of the source network, then
we need an automatic routing protocol which supports transit networks.

Whether that is within the speermint charter, is open for discussion.

I don't doubt that we need somethings like this in the long run.

Even the NGN guys & gals over in the ITU/ETSI/3GPP world are facing the
same problem and as far as I know, they haven't found the magic bullet yet.

/ol

proposals (draft-lendl-domain-policy-ddds-02 +
draft-lendl-speermint-federations-03) propose to use

- I-ENUM to map TN to SIP URIs

- a DDDS application to map the domain part of those URIs to federation
  identifiers

- Route based on the federation IDs. (in the best case: just route via
  a shared federation)

You could save one step by storing the federation IDs directly in
I-ENUM, but you loose the possibility to do URI-based calls with the
same framework.

> achieved by VSPs in very entity-specific way and not in need of inter- 

Right now, we're seeing a lot of ad-hoc peering with hand-spun route
advertisements. Whatever transit traffic is currently passed via SIP,
the routing seems to be mainly done via manual, static routes.

If we ever want to get rid of the PSTN as the "default route" to be
uses when the destination isn't a peer of the source network, then
we need an automatic routing protocol which supports transit networks.

Whether that is within the speermint charter, is open for discussion.

I don't doubt that we need somethings like this in the long run.

Even the NGN guys & gals over in the ITU/ETSI/3GPP world are facing the
same problem and as far as I know, they haven't found the magic bullet yet.

/ol

---

From: Andrew Newton <[email-masked]>
Date: Mon, 26 Feb 2007 11:54:58 -0500

>   are better suited for a routing protocol.

Once you've done this, you are exactly at the point of an Internet  
email model.

> * Build a routing protocol on top of these identifiers.

Do Internet email providers relay email through each other day?  No.   
In fact, relaying is not considered good practice anymore.  I think  
this will work even worse with SIP.

> - I-ENUM to map TN to SIP URIs

[..snip..]

> we need an automatic routing protocol which supports transit networks.

There is a disconnect here with stating a goal of getting rid of the  
PSTN by using I-ENUM.  As far as I can tell, the entire purpose of I- 
ENUM is about the incumbent PSTN players retaining their strict control.

-andy

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Mon, 26 Feb 2007 16:58:17 +0000

Isn't any issue relating to telephone numbers, an ENUM issue?  
 
It does seem to me that [infrastructure] ENUM, if it does this
successfully, is effectively a global LNP system.  Maybe people are
questioning whether that will succeed?  While I can be as skeptical as
the next guy, I'm struggling to understand how this has become a
speermint issue.
 
tim

________________________________

	From: Andrew Newton [mailto:[email-masked]] 
	Sent: Monday, February 26, 2007 9:53 AM
	To: Creighton, Tom
	Cc: Otmar Lendl; [email-masked]
	Subject: Re: [Speermint] Multihop routing

		I do not agree that TRIP is a viable option for the
countries that

		support number portability.  It would be the equivalent
to trying to

		aggregate your IP routes in BGP if you allowed your
customers to keep

		their IP addresses when they sign up for or cancel their
Internet

	That is an interesting observation.  But it begs the question,
how will any multi-hop routing work with number portability then?

	I also wonder if this is a theoretical problem?  While I
understand the goal, it isn't a problem we experience today.  That's not
to say that nobody does multi-hop routing today, but that it is usually
achieved by VSPs in very entity-specific way and not in need of
inter-domain coordination.

	-andy

---

From: "PFAUTZ, PENN L, TCORP" <[email-masked]>
Date: Mon, 26 Feb 2007 11:01:55 -0500

Beyond number portability and scaling, TRIP presents a number of other
issues that prevent its wide deployment.
Among these are...
Most telephone numbers are still not reachable via IP and most thus also
require somebody pay intercarrier compensation. Under these
circumstances, who's going to advertise reachability to numbers without
commercial arrangements? And where those arrangements have been
negotiated, TRIP may not be necessary.

Penn Pfautz

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 10:47 AM
To: [email-masked]
Subject: Re: [Speermint] Multihop routing

> This sounds like RFC 3219.

Yes, TRIP tries to address the same issue, at least for TN based
routing.

/ol

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 26 Feb 2007 19:48:06 +0100

Excactly
 
I-ENUM is out of scope in Speermint
 
I have really no idea why everybody is talking about phone numbers
 
The task of speermint is to solve interconnection based on URIs
 
We have to keep this separate
 
Richard

Von: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Gesendet: Mo 26.02.2007 17:58
An: [email-masked]
Betreff: RE: [Speermint] Multihop routing

It does seem to me that [infrastructure] ENUM, if it does this successfully, is effectively a global LNP system.  Maybe people are questioning whether that will succeed?  While I can be as skeptical as the next guy, I'm struggling to understand how this has become a speermint issue.
 
tim

	That is an interesting observation.  But it begs the question, how will any multi-hop routing work with number portability then?

	I also wonder if this is a theoretical problem?  While I understand the goal, it isn't a problem we experience today.  That's not to say that nobody does multi-hop routing today, but that it is usually achieved by VSPs in very entity-specific way and not in need of inter-domain coordination.

	-andy

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 26 Feb 2007 23:05:10 +0100

> Isn't any issue relating to telephone numbers, an ENUM issue?  

Not quite. Some people do TN -> SIP nexthop lookup with SIP 3xx
responses.

> the next guy, I'm struggling to understand how this has become a

Speermint isn't going to deal with I-ENUM.

The range of potential speermint solutions just changes if you can
assume a working I-ENUM infrastructure.

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 26 Feb 2007 22:56:43 +0100

> Once you've done this, you are exactly at the point of an Internet  

No. On two counts:

* I don't think we should map TNs to IP-addresses

* The "email model" has not only technical connotations, it also
  describes an ecosystem. The basic premise is that anybody can connect
  to a mail server which is listed in a MX record for a domain and
  transmit mails addressed to that domain. No questions asked, no
  contacts signed, no money exchanged.

  That is not how the ecosystem of the phone business works. Nothing
  that speermint can do is going to change that in the short term.

> this will work even worse with SIP.

Right now, the huge majority of carriers will only accept calls via SIP
to their customers if they get money for every call. If they reject the
call, then the originating network must fall back to the PSTN which
completes the call and arranges for the destination network to get paid.

Thus there is _no_ motivation for carriers to allow anonymous SIP
proxies to places calls to their customers, as "no business
relationship" implies "no termination fee".

In theory, every VSP could establish such a business relationship with
every other VSP in the world. Thus everybody has a peering relationship
with everybody else, everybody is happy and not even the happy tree
friends get hurt.

That just doesn't scale. There is no benefit for a small Korean VoIP
operator to enter into a contract with a small VoIP service in Tyrol.
The number of calls between those two will in all likelihood be zero.

There is thus a market for aggregators. For carriers to act as
transit networks to take the sting out of the O(n*n) scaling of
a full mesh.

Yes, transit networks (relays) make little sense for email. They do
make sense for PSTN-replacement SIP, as they act as

* Payment aggregators

  See above.

* Trust proxies

  If my users complain about nuisance call, SPIT, stalking, .. I have
  a contract with the party from whom I received those calls. I can
  hold them accountable for the behavior of their users.

* DoS protection

  If I just need to open my ingress elements to a known set of 
  transit carriers and peers, it is a lot simpler to protect them
  against DoS attacks.

* SIP compatibility

  Given the state of SIP implementations these days, such aggregators
  also have a role to get consistent performance and features.

  (Yes, it's that bad. Just the other day I had to debug an issue
  with a German operator which insisted to route calls based on the
  To: header instead of the request URI. I've run into enough issues
  with SIP enabled PBXs which don't do call-transfers correctsly
  when called directly via SIP and not via their PSTN gateway.
  I'm sure Eli can tell you some more riveting stories about the quality
  of SIP implementations.)

I see zero chance that the carrier world moves to an email-style
interconnection regime within the next decade. I'd be pleasantly
surprised if the guys from AT&T, Global Crossing, L3 & co prove me
wrong on this. Adam? Penn? Daryl?

> >uses when the destination isn't a peer of the source network, then we
> >need an automatic routing protocol which supports transit networks.
>
> PSTN by using I-ENUM.  As far as I can tell, the entire purpose of
> I- ENUM is about the incumbent PSTN players retaining their strict
> control.

I-ENUM is for carriers to help them move from SS7 to SIP. That does
not mean the business foundations change dramatically.

User ENUM has the potential to wrestle control from carriers (especially
for corporate users). Btw, what's keeping the NANP from implementing it?

/ol

---

From: Andrew Newton <[email-masked]>
Date: Mon, 26 Feb 2007 20:33:59 -0500

> * I don't think we should map TNs to IP-addresses

DNS does not map email addresses to IP addresses.  It maps email  
domains to IP addresses.  The connection model you are describing is  
the same.  But you are right that VSPs are much, much more  
restrictive from whom they will accept traffic.

> transit networks to take the sting out of the O(n*n) scaling of

I'm well aware of these players.  I've personally talked to most of  
them at one time or another.  Perhaps they are in need of multi-hop  
routing between their respective domains, but that class of problem  
is not the entirety of the space.  And I'm unaware why TRIP couldn't  
be used to satisfy their needs.  Perhaps NP is an issue, but I don't  
see how an extra layer of indirection helps in that case.

> wrong on this. Adam? Penn? Daryl?

FYI... not all VSPs are the carrier-of-record.

> not mean the business foundations change dramatically.

Thanks for verifying my assumption.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Mon, 26 Feb 2007 20:47:40 -0500

> The task of speermint is to solve interconnection based on URIs

Oh.  Ok.  Can we get a show of hands from the VSPs who start and base  
routing only on URIs?

-andy

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 27 Feb 2007 12:25:38 +0100

> see how an extra layer of indirection helps in that case.

It reduces the complexity of the routing problem from O(#numbers) to
O(#carriers). I don't have the statistics for the US market, but I guess
that means going from a few hundred millions down to a few thousands.
That are five orders of magnitude.

> FYI... not all VSPs are the carrier-of-record.

In the US. Things are different in other countries. e.g. in Austria
even a small VoIP operator gets his numbers directly from the
regulatory authority. He will likely contract some larger operator
to arrange for the routing inside the PSTN, but he owns the numbers
and thus controls the I-ENUM entries.

For the US, there might be a case for two variations of I-ENUM,
one which mirrors the LERG, and a second where the Vonages & co
can make their entries.  (Adding that tree would be trivial using
the short-term proposal for combined i-enum. But that's a topic
for the ENUM wg.)

> Thanks for verifying my assumption.

Interestingly enough, Richard Shockey talks a lot about
I-ENUM defining new "business relationships" and "carrier
business rules or carrier to carrier business structures" in
http://www1.ietf.org/mail-archive/web/enum/current/msg05529.html

You thus should not rely on my word. I recommend you contact our
esteemed ENUM WG chair and cross-check your assumptions with him.

/ol

---

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 27 Feb 2007 10:35:59 -0500

Though ENUM is certainly out of scope, there needs to be an
acknowledgement that ENUM does, can and, as it's being argued in the
thread, should be a lively topic for SIP Peering in general.  I don't
see any harm in delving into the topic on here.  From a macro-level
point of view, ENUM needs to be acknowledged and understood in
conjunction to the SPEERMINT-specific charter items.  As it pertains to
I-ENUM and peering, I believe the ultimate end for the most effective
SIP Peering model necessitates I-ENUM. It's another matter entirely if
the goal is achievable. A model with I-ENUM, DDDS, SIP policy, etc = is
really the only way to offer a well-balanced solution for those with
consumer, commercial and practical interests at heart.  

-AU

> Sent: Tuesday, February 27, 2007 6:26 AM
> To: [email-masked]
<snip>
> You thus should not rely on my word. I recommend you contact 
> our esteemed ENUM WG chair and cross-check your assumptions with him.
> 
> /ol
> --

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 27 Feb 2007 10:50:58 -0500

I got a little bit confused. In Speermint, we are talking about routing
sip-uri, so this is about routing domain. Imagine we have an enum
database that can match every tn to sip-uri. For outbound traffic, you
will have full control inside your domain. For inbound traffic, you can
publish the border element to dns to control which element you want the
inbound traffic to enter to your domain. In federation, you can ask your
VSP to publish your domain to point to their border elements. If you
really want to give a different view of your border elements to
different VSPs, then you may want to create different ENUM views to
different VSPs. We don't need a routing protocol to handle emails, so
neither do we.

From: Dwight, Timothy M (Tim) [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 11:58 AM
To: [email-masked]
Subject: RE: [Speermint] Multihop routing

 
tim

	-andy

---

From: "Egbert, Brian G [CTO]" <[email-masked]>
Date: Tue, 27 Feb 2007 10:06:51 -0600

I normally refrain but I find I must agree with this.

Brian

[email-masked]  

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Tuesday, February 27, 2007 9:36 AM
To: Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Multihop routing

Though ENUM is certainly out of scope, there needs to be an acknowledgement that ENUM does, can and, as it's being argued in the thread, should be a lively topic for SIP Peering in general.  I don't see any harm in delving into the topic on here.  From a macro-level point of view, ENUM needs to be acknowledged and understood in conjunction to the SPEERMINT-specific charter items.  As it pertains to I-ENUM and peering, I believe the ultimate end for the most effective SIP Peering model necessitates I-ENUM. It's another matter entirely if the goal is achievable. A model with I-ENUM, DDDS, SIP policy, etc = is really the only way to offer a well-balanced solution for those with consumer, commercial and practical interests at heart.  

-AU

<snip>
> 
> Interestingly enough, Richard Shockey talks a lot about I-ENUM 
> defining new "business relationships" and "carrier business rules or 
> carrier to carrier business structures" in