Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

From: Daryl Malas <[email-masked]>
Date: Mon, 1 Mar 2010 16:50:51 -0700

All,

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : SIP Egress Route Use in ENUM
Author(s) : D. Malas
Filename : draft-malas-dispatch-sip-egress-route-00.txt
Pages : 11
Date : 2010-03-01

In some cases a UA (or proxy) within a Session Initiation Protocol
[RFC3261] Service Provider (SSP) has multiple parallel egress proxy
options to reach an ingress proxy within another SSP to reach the
target UA. If the originating SSP uses ENUM to identify the ingress
proxy of the target SSP, there is currently no way for the ENUM NAPTR
response to identify a specific preferred egress proxy from the set
of multiple parallel proxies. This draft solves this problem by
defining a method for returning deterministic routing information
within an ENUM NAPTR response enabling the UA (or proxy) to choose a
preferred egress proxy. Using this information, the originating UA
now sends the SIP request through the predetermined preferred egress
proxy to reach the target SSP's proxy. This document describes
several methods to make this determination by incorporating variables
into a SIP service URI contained in the E.164 Number Mapping (ENUM)
response.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-route-00.txt <mailto:[email-masked]>

Regards,

Daryl

---------------------------
Daryl Malas
Project Director, IP Interconnects
w - +1 303 661 3302
mailto:[email-masked]<blocked::mailto:[email-masked]>

---

From: Dean Willis <[email-masked]>
Date: Tue, 2 Mar 2010 12:36:06 -0600

> Filename : draft-malas-dispatch-sip-egress-route-00.txt

The universe has apparently shifted beneath my feet again. When did  
DNS (and ENUM is just DNS, or maybe a private-root DNS depending on  
what you believe) become a legitimate repository for intermediary  
routing information?

Let's take the scenario from the draft:

    +=====================++                 ++====================+
                          ||                 ||
        SSP1 Network  +--------+             ||       SSP2 Network
    ssp1.example.com  |        |             ||   ssp2.example.com
                 +--->|  SBE1  |---+         ||
                 |    |        |   |         ||
                 |    +--------+   |         ||
                 |        ||       |         ||
                 |        ||       |         ||
     +-------+   |        ||       |     +--------+     +-------+
     |       |---+        ||       +---->|        |---->|       |
     | Proxy |            ||             |  SBE3  |     | Proxy |
     |       |---+        ||       +---->|        |---->|       |
     +-------+   |        ||       |     +--------+     +-------+
                 |        ||       |         ||
                 |        ||       |         ||
                 |    +--------+   |         ||
                 |    |        |   |         ||
                 +--->|  SBE2  |---+         ||
                      |        |             ||
                      +--------+             ||
                          ||                 ||
    +=====================++                 ++====================+

Here's the scenario recast in a "more traditional" terminology:

SSP2 has externally advertised (at least to SSP1) that SBE3 is a (or  
"the") route to the address space of SSP2. Both SBE1 and SBE2 have  
been informed of this advertisement. Presumably there's a route in the  
other direction as well, although that's out of scope for the example.

SSP1 wishes to advertise, within the administrative domain of SSP1,  
two routes to the address space of SSP2. The preferred route is  
through SBE2, with a secondary route through SBE1, although nothing  
has been said about the load-metric so we assume the policy use "Use  
SBE1 only if SBE2 isn't responding".

Explain to me why ANY of this routing/reachability information should  
be in DNS or a DNS-like static map? That's just absurd! We appear to   
going through some extreme convolutions to twist a dynamic routing  
problem (that should be dealt with by protocols more like BGP and  
OSPF) into a name-service problem.

I think it's time for a complete re-think of what's going on here.

ENUM is NOT a routing protocol. It's a distributed database for  
mapping names to addresses and for looking up related information  
about names, where the associations involved are relatively long-lived  
(and for the most part effectively static).

There's a reason we don't have every Internet router do a DNS lookup  
on a request-destination and use that lookup result to select a next- 
hop route. We COULD do this, it just requires having lots and lots of  
DNS servers configured with alt-root structures that reflect local  
routing tables, and that get continuously reprovisioned to reflect  
changes in network topology, load, and policy.  We COULD do this --  
why don't we?  The answer is that doing this would be deeply,  
profoundly, and astoundingly inefficient. It's just the wrong way to  
solve the problem. It's sort of like trying to print highway maps  
that, rather than showing the road to follow to reach a destination,  
only show the next exit or turn and therefore one needs an entirely  
different map for each possible place that one might currently be  
standing. Sure, it makes for a big business in maintaining and  
printing maps, but it makes actually getting anywhere profoundly  
painful and expensive.

So why on earth are we attempting to use the same pattern for routing  
phone calls?  Is it just a matter of ENUM being the only hammer we  
were given to play with? Folks, we can get a different tool if we need  
one; we don't need to keep beating on the plumbing with the ENUM  
hammer when what we really need is a pipe-threader or bender.

--
Dean

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Tue, 2 Mar 2010 14:24:21 -0500

Daryl:

I want to be sure I understand what you're proposing.  In what name
server would the modified records be? One local to SSP1 or some general
industry DNS? I'm trying to understand how SSP1 modifies an RR for an
SSP2 number.

Thanks,

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Daryl Malas
Sent: Monday, March 01, 2010 6:51 PM
To: [email-masked]'
Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

All,

A New Internet-Draft is available from the on-line Internet-Drafts
directories. 

 
A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-rout
e-00.txt 

Regards,

Daryl

Daryl Malas

w - +1 303 661 3302

mailto:[email-masked] <blocked::mailto:[email-masked]>

---

From: Adam Roach <[email-masked]>
Date: Tue, 02 Mar 2010 13:26:01 -0600

> what you believe) become a legitimate repository for intermediary 

1992?

http://www.rfc-editor.org/rfc/rfc1383.txt

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 02 Mar 2010 13:52:41 -0600

> http://www.rfc-editor.org/rfc/rfc1383.txt

And, really, if you look at the original DNS spec (RFC 882, published in 
1983), the MF record type (as distinct from the MD record type, both 
since subsumed by MX records) talk about the same kinds of information 
as Daryl is proposing here. Semantically: "To get to host B, deliver to 
host A, and indicate the domain of host B in the application data itself."

There's also the use of the "RT" (Route Through) record defined by RFC 
1183, which does exactly this kind of thing. In fact, a careful dusting 
off of RT (accompanied by a BCP for this specific application) would 
probably serve the purpose intended by this draft.

I really see very little historical basis for objecting to storing this 
kind of information in DNS at all.

/a

---

From: Dean Willis <[email-masked]>
Date: Wed, 3 Mar 2010 00:59:15 -0600

> http://www.rfc-editor.org/rfc/rfc1383.txt

That was what we might colloquially  call a "valid experiment that  
successfully produced a result invalidating the hypothesis". Bravely  
done, but perhaps not so functional in the real world.  An  
experimental approach resulting in failure does not qualify the failed  
approach as a legitimate solution.

Do we learn from it, or just blindly do it all over again?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 3 Mar 2010 01:05:43 -0600

On Mar 2, 2010, at 1:52 PM, Adam Roach wrote:

>
> And, really, if you look at the original DNS spec (RFC 882,  
> published in 1983), the MF record type (as distinct from the MD  
> record type, both since subsumed by MX records) talk about the same  
> kinds of information as Daryl is proposing here. Semantically: "To  
> get to host B, deliver to host A, and indicate the domain of host B  
> in the application data itself."
>
> There's also the use of the "RT" (Route Through) record defined by  
> RFC 1183, which does exactly this kind of thing. In fact, a careful  
> dusting off of RT (accompanied by a BCP for this specific  
> application) would probably serve the purpose intended by this draft.
>
> I really see very little historical basis for objecting to storing  
> this kind of information in DNS at all.

The unused routing cruft in the DNS is unused for a reason; it doesn't  
make for an operational network or a scaleable DNS. This is also why  
we don't use UUCP-style addressing for phone calls and web traffic.

The applicability of the approach can be summed up in the non-response  
to:

http://www.ops.ietf.org/lists/namedroppers/namedroppers.199x/msg00915.html

But you are right;  RT does almost exactly what the draft in question  
proposes. I wouldn't stop anybody from doing an experimental-track  
draft warming over RT for phone number routing. But I'd probably laugh  
at them.

--
Dean

---

From: Greger Viken Teigre <[email-masked]>
Date: Wed, 03 Mar 2010 08:16:05 +0100

On 02.03.2010 20:24, PFAUTZ, PENN L (ATTCORP) wrote:
> server would the modified records be? One local to SSP1 or some 
> general industry DNS? I'm trying to understand how SSP1 modifies an RR 
> for an SSP2 number.
>

A few follow-up questions to that. I'm a bit confused about the problem 
that you are trying to solve.

 From the draft it looks like the name server is local to SSP1. If that 
is correct, why would you like to standardize how you acquire routing 
information? If both the proxy and the name server are local to SSP1, I 
don't see why you need to standardize the data retrieval interface in a 
SIP context?  We already have a few of those.  And there must surely be 
more efficient ways of storing and retrieving such information?!
However, if the intention is primarily to be a standard for UAs to 
implement to avoid a ("static") proxy for determining routing path (i.e. 
a per session outbound proxy), we should surely look at a more generic 
approach to determining the outbound proxy?!  I thought dynamic routing 
was one of the reasons for having an outbound proxy and choosing an 
egress proxy is hardly a problem specific to e.164 addresses.
g-)

> Thanks,
>
> Penn Pfautz
>
> AT&T Access Management
>
> +1-732-420-4962
>
> *From:* [email-masked] [mailto:[email-masked]] 
> *On Behalf Of *Daryl Malas
> *Sent:* Monday, March 01, 2010 6:51 PM
> *To:* [email-masked]'
> *Subject:* [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00
>
> All,
>
> http://www.ietf.org/internet-drafts/draft-malas-dispatch-sip-egress-route-00.txt 
>
>
> Regards,
>
> Daryl
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Daryl Malas <[email-masked]>
Date: Wed, 3 Mar 2010 09:21:52 -0700

Penn,

The use case for this application is SSP1 (or someone on their behalf) provisions their numbers and relative routes into the LUF associated with their federation.  SSP2 reviews SSP1's "routes" available to them in the LUF based on what SSP1 provisioned.  They then add an egress route and associate it with the ingress route SSP1 provisioned.

Let me know if this makes sense.

Regards,

Daryl

________________________________
From: PFAUTZ, PENN L (ATTCORP) [mailto:[email-masked]]
Sent: Tuesday, March 02, 2010 12:24 PM
To: Daryl Malas; [email-masked]
Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

Daryl:
I want to be sure I understand what you're proposing.  In what name server would the modified records be? One local to SSP1 or some general industry DNS? I'm trying to understand how SSP1 modifies an RR for an SSP2 number.

Thanks,

Penn Pfautz
AT&T Access Management
+1-732-420-4962
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daryl Malas
Sent: Monday, March 01, 2010 6:51 PM
To: [email-masked]'
Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

All,

Regards,

Daryl

---

From: Daryl Malas <[email-masked]>
Date: Wed, 3 Mar 2010 09:26:51 -0700

Greger,

Please see my last email in response to Penn and let me know if it helps.

Regards,

Daryl

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greger Viken Teigre
Sent: Wednesday, March 03, 2010 12:16 AM
To: [email-masked]
Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

A few follow-up questions to that. I'm a bit confused about the problem that you are trying to solve.

>From the draft it looks like the name server is local to SSP1. If that is correct, why would you like to standardize how you acquire routing information? If both the proxy and the name server are local to SSP1, I don't see why you need to standardize the data retrieval interface in a SIP context?  We already have a few of those.  And there must surely be more efficient ways of storing and retrieving such information?!
However, if the intention is primarily to be a standard for UAs to implement to avoid a ("static") proxy for determining routing path (i.e. a per session outbound proxy), we should surely look at a more generic approach to determining the outbound proxy?!  I thought dynamic routing was one of the reasons for having an outbound proxy and choosing an egress proxy is hardly a problem specific to e.164 addresses.
g-)

Thanks,
Penn Pfautz
AT&T Access Management
+1-732-420-4962
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Daryl Malas
Sent: Monday, March 01, 2010 6:51 PM
To: [email-masked]<mailto:[email-masked]>'
Subject: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00
All,
A New Internet-Draft is available from the on-line Internet-Drafts directories.

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Daryl Malas <[email-masked]>
Date: Wed, 3 Mar 2010 09:31:34 -0700

Penn,

Just to continue my thought a bit further, the UI associated with adding and managing the "egress route" is out of scope of this draft.  The purpose of this draft is to define a standard approach for first, defining what the egress route should look like and then how it should be conveyed in the NAPTR.

Regards,

Daryl

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daryl Malas
Sent: Wednesday, March 03, 2010 9:22 AM
To: 'PFAUTZ, PENN L (ATTCORP)'; [email-masked]
Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

Penn,

Regards,

Daryl

Daryl:

Thanks,

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

All,

Regards,

Daryl

---

From: Adam Roach <[email-masked]>
Date: Wed, 03 Mar 2010 10:41:17 -0600

On 3/3/10 10:31 AM, Daryl Malas wrote:
> Just to continue my thought a bit further, the UI associated with 
> adding and managing the "egress route" is out of scope of this draft.  
> The purpose of this draft is to define a standard approach for first, 
> defining what the egress route should look like and then how it should 
> be conveyed in the NAPTR.
>

And, to be clear, what I read in this document (if we discard the third 
alternative that it discusses but clearly does not favor) is of the 
nature of a BCP, not a standard. The first two alternatives don't 
actually change existing protocols or propose any new protocols -- they 
show how existing protocols can be used to achieve the stated goal.

It looks like more of a clever, "hey, guys, I figured out a way to 
scratch an itch I had, and here's how I did it" kind of thing. I believe 
it would be useful to publish in that context.

/a

---

From: Daryl Malas <[email-masked]>
Date: Wed, 3 Mar 2010 09:48:30 -0700

Dean,

I don't agree with your map analogy.  Every hop along the way in the draft example does not require a new look-up.  The single ENUM response provides all of the information necessary to reach the target.  It just includes "next hop" information to provide more intelligent routing.  The final target information is still contained in the single response. Perhaps the reason ENUM may be a little different is based on the application associated with the NAPTR.  SIP is an intelligent application with the ability to receive detailed information to reach the target UA.  The draft just leverages the SIP service NAPTR to provide the SIP application with more of this detailed information.  This way information does not need to be stored and managed in many different locations.

Regards,

Daryl

________________________________
From: Dean Willis [mailto:[email-masked]]
Sent: Tuesday, March 02, 2010 11:36 AM
To: Daryl Malas
Cc: [email-masked]'
Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

All,

The universe has apparently shifted beneath my feet again. When did DNS (and ENUM is just DNS, or maybe a private-root DNS depending on what you believe) become a legitimate repository for intermediary routing information?

SSP2 has externally advertised (at least to SSP1) that SBE3 is a (or "the") route to the address space of SSP2. Both SBE1 and SBE2 have been informed of this advertisement. Presumably there's a route in the other direction as well, although that's out of scope for the example.

SSP1 wishes to advertise, within the administrative domain of SSP1, two routes to the address space of SSP2. The preferred route is through SBE2, with a secondary route through SBE1, although nothing has been said about the load-metric so we assume the policy use "Use SBE1 only if SBE2 isn't responding".

Explain to me why ANY of this routing/reachability information should be in DNS or a DNS-like static map? That's just absurd! We appear to  going through some extreme convolutions to twist a dynamic routing problem (that should be dealt with by protocols more like BGP and OSPF) into a name-service problem.

ENUM is NOT a routing protocol. It's a distributed database for mapping names to addresses and for looking up related information about names, where the associations involved are relatively long-lived (and for the most part effectively static).

There's a reason we don't have every Internet router do a DNS lookup on a request-destination and use that lookup result to select a next-hop route. We COULD do this, it just requires having lots and lots of DNS servers configured with alt-root structures that reflect local routing tables, and that get continuously reprovisioned to reflect changes in network topology, load, and policy.  We COULD do this -- why don't we?  The answer is that doing this would be deeply, profoundly, and astoundingly inefficient. It's just the wrong way to solve the problem. It's sort of like trying to print highway maps that, rather than showing the road to follow to reach a destination, only show the next exit or turn and therefore one needs an entirely different map for each possible place that one might currently be standing. Sure, it makes for a big business in maintaining and printing maps, but it makes actually getting anywhere profoundly painful and expensive.

So why on earth are we attempting to use the same pattern for routing phone calls?  Is it just a matter of ENUM being the only hammer we were given to play with? Folks, we can get a different tool if we need one; we don't need to keep beating on the plumbing with the ENUM hammer when what we really need is a pipe-threader or bender.

--
Dean

---

From: Daryl Malas <[email-masked]>
Date: Wed, 3 Mar 2010 09:51:11 -0700

Adam,

You "hit the nail on the head."  This is the exact intension of this draft.

--Daryl

________________________________
From: Adam Roach [mailto:[email-masked]]
Sent: Wednesday, March 03, 2010 9:41 AM
To: Daryl Malas
Cc: 'PFAUTZ, PENN L (ATTCORP)'; [email-masked]
Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

And, to be clear, what I read in this document (if we discard the third alternative that it discusses but clearly does not favor) is of the nature of a BCP, not a standard. The first two alternatives don't actually change existing protocols or propose any new protocols -- they show how existing protocols can be used to achieve the stated goal.

It looks like more of a clever, "hey, guys, I figured out a way to scratch an itch I had, and here's how I did it" kind of thing. I believe it would be useful to publish in that context.

/a

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Wed, 3 Mar 2010 12:37:31 -0500

Daryl 

I was a little confused by this since I thought the call was from SSP1
to SSP2 and that SSP2 provisioned its numbers into the registry. If SSP1
get the SSP2 data and wants to add their egress routes in their local
copy I can see that but I wouldn't expect the resulting elaborated
NAPTRs to be in the Registry. 

Have I got this right now?

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From: Daryl Malas [mailto:[email-masked]] 
Sent: Wednesday, March 03, 2010 11:22 AM
To: PFAUTZ, PENN L (ATTCORP); [email-masked]
Subject: RE: [dispatch] I-D Action:
draft-malas-dispatch-sip-egress-route-00

Penn,

The use case for this application is SSP1 (or someone on their behalf)
provisions their numbers and relative routes into the LUF associated
with their federation.  SSP2 reviews SSP1's "routes" available to them
in the LUF based on what SSP1 provisioned.  They then add an egress
route and associate it with the ingress route SSP1 provisioned.

Regards,

Daryl

From: PFAUTZ, PENN L (ATTCORP) [mailto:[email-masked]] 
Sent: Tuesday, March 02, 2010 12:24 PM
To: Daryl Malas; [email-masked]
Subject: RE: [dispatch] I-D Action:
draft-malas-dispatch-sip-egress-route-00

Daryl:

Thanks,

Penn Pfautz

AT&T Access Management

+1-732-420-4962

All,

 

Regards,

Daryl

Daryl Malas

w - +1 303 661 3302

---

From: Daryl Malas <[email-masked]>
Date: Wed, 3 Mar 2010 11:01:04 -0700

Penn,

I think what you're describing is leaning towards implementation specific questions.  I apologize, my example below is backwards, but the principle is the same.  SSP2 provisions their numbers and "routes" into the ENUM server.  SSP1 can see the ingress routes for SSP2 numbers.  SSP1 can then specify their own egress routes in the same ENUM server.

The method for SSP1's egress routes for SSP2 to be received into a "local copy" is implementation specific, imo.  This being said, obviously, SSP3 and SSP4 would not (want to) see SSP1's provisioned egress routes for SSP2 when they query the ENUM server.  If this is resolved in some "for queries from here give this" or "here is a local copy of peer numbers and routes plus *your* egress routes" is implementation specific.

Regards,

Daryl

Sent: Wednesday, March 03, 2010 10:38 AM

Daryl
I was a little confused by this since I thought the call was from SSP1 to SSP2 and that SSP2 provisioned its numbers into the registry. If SSP1 get the SSP2 data and wants to add their egress routes in their local copy I can see that but I wouldn't expect the resulting elaborated NAPTRs to be in the Registry.
Have I got this right now?

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

Penn,

Regards,

Daryl

Thanks,

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

All,

Regards,

Daryl

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Wed, 3 Mar 2010 13:11:08 -0500

Daryl:

Thanks. I now understand what you're after and it is just the
implementation questions that concern me.  It might be useful to make
clear you're not proposing any specific implementation.

For example, in a different context (drinks) if it were proposed to
support building these kinds of records in the registry as opposed to
the SSP1 network  I'd probably be agin it.

Thanks for the clarification

Penn Pfautz

AT&T Access Management

+1-732-420-4962

Sent: Wednesday, March 03, 2010 1:01 PM

Penn,

I think what you're describing is leaning towards implementation
specific questions.  I apologize, my example below is backwards, but the
principle is the same.  SSP2 provisions their numbers and "routes" into
the ENUM server.  SSP1 can see the ingress routes for SSP2 numbers.
SSP1 can then specify their own egress routes in the same ENUM server.

The method for SSP1's egress routes for SSP2 to be received into a
"local copy" is implementation specific, imo.  This being said,
obviously, SSP3 and SSP4 would not (want to) see SSP1's provisioned
egress routes for SSP2 when they query the ENUM server.  If this is
resolved in some "for queries from here give this" or "here is a local
copy of peer numbers and routes plus *your* egress routes" is
implementation specific.

Regards,

Daryl

Daryl 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

Penn,

Regards,

Daryl

Daryl:

Thanks,

Penn Pfautz

AT&T Access Management

+1-732-420-4962

All,

 

Regards,

Daryl

Daryl Malas

w - +1 303 661 3302

---

From: Dean Willis <[email-masked]>
Date: Wed, 3 Mar 2010 13:26:21 -0600

On Mar 3, 2010, at 10:48 AM, Daryl Malas wrote:

> Dean,
>
> I don't agree with your map analogy.  Every hop along the way in the  
> draft example does not require a new look-up.  The single ENUM  
> response provides all of the information necessary to reach the  
> target.  It just includes "next hop" information to provide more  
> intelligent routing.  The final target information is still  
> contained in the single response. Perhaps the reason ENUM may be a  
> little different is based on the application associated with the  
> NAPTR.  SIP is an intelligent application with the ability to  
> receive detailed information to reach the target UA.  The draft just  
> leverages the SIP service NAPTR to provide the SIP application with  
> more of this detailed information.  This way information does not  
> need to be stored and managed in many different locations.
>

But the "egress route" returned by the ENUM lookup is dependent on  
where the lookup is happening, right? This means lots of different  
ENUM databases that return different values for queries on the same  
key. This is the exact antithesis of the scalability model of DNS,  
which is predicated on universally-valid results that allow  
dissemination through recursive lookups and caching.

If each of SSP1 and SSP2 interconnects with SSP3, the "egress route"  
from SSP1 to SSP3 is NOT the same as the route from SSP2 to SSP3.

So the ENUM database seen by nodes at SSP1 returns different values  
from the ENUM database seen by nodes at SSP2, which is different yet  
again for nodes at SSP3. This means that for the "SSP3" key, at least  
two different context-dependent values are being stored in the  
databases. It's just not how DNS was designed to distribute. Yeah, it  
sort of works if you assume lots of independently provisioned  
databases, but it's still an operational nightmare and all you're  
getting out of ENUM is a standardized database format.

You have here a very real problem that is exactly analogous to the IP- 
level route-peering problem. Many years of working this problem at the  
IP level have shown that statically provisioned databases (aka DNS)  
are NOT an effective way to solve the problem at a large scale. DNS  
provides a nice mechanism for turning a name (or phone number) into a  
target IP address, but a lousy mechanism for telling us each of the  
intermediate hops needed to get from a source IP address to a target  
IP address (which is a vector of the router in between the two  
addresses).

We really need a SIP-targeted analog of the BGP/OSPF route-exchange  
protocols to solve the general problem.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 3 Mar 2010 13:30:12 -0600

On Mar 3, 2010, at 12:01 PM, Daryl Malas wrote:

> resolved in some "for queries from here give this" or "here is a  
> local copy of peer numbers and routes plus *your* egress routes" is  
> implementation specific.

And this part right here is exactly why the DNS infrastructure of ENUM  
is NOT a good solution for the problem. Unlike Einstein, DNS does not  
embrace relativity (AKA location-context sensitivity). There are ugly  
hacks to make relativity happen in certain limited cases, but they  
defeat the fundamental scalability mechanisms of the DNS.

--
Dean

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Wed, 3 Mar 2010 14:40:40 -0500

Ah, this is exactly why the GSMA chose to handle the problem by moving
it to layer 3:  The IPX carriers implement a private IP network through
which connecting service providers advertise the IP addresses of their
border elements via BGP. An ENUM lookup resolves to a common IP address
for all querying parties but each SP associates the IP address with a
route learned from their chosen IPX provider. This is, of course, just
the basic Internet approach moved off the "public" Internet. It also
works for bilateral direct connections and, in principle, should prefer
such connections over a route through an IPX provider where both are
available.  

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Wednesday, March 03, 2010 2:26 PM
To: Daryl Malas
Cc: [email-masked]'
Subject: Re: [dispatch] I-D Action:
draft-malas-dispatch-sip-egress-route-00

Dean,

I don't agree with your map analogy.  Every hop along the way in the
draft example does not require a new look-up.  The single ENUM response
provides all of the information necessary to reach the target.  It just
includes "next hop" information to provide more intelligent routing.
The final target information is still contained in the single response.
Perhaps the reason ENUM may be a little different is based on the
application associated with the NAPTR.  SIP is an intelligent
application with the ability to receive detailed information to reach
the target UA.  The draft just leverages the SIP service NAPTR to
provide the SIP application with more of this detailed information.
This way information does not need to be stored and managed in many
different locations.

But the "egress route" returned by the ENUM lookup is dependent on where
the lookup is happening, right? This means lots of different ENUM
databases that return different values for queries on the same key. This
is the exact antithesis of the scalability model of DNS, which is
predicated on universally-valid results that allow dissemination through
recursive lookups and caching.

So the ENUM database seen by nodes at SSP1 returns different values from
the ENUM database seen by nodes at SSP2, which is different yet again
for nodes at SSP3. This means that for the "SSP3" key, at least two
different context-dependent values are being stored in the databases.
It's just not how DNS was designed to distribute. Yeah, it sort of works
if you assume lots of independently provisioned databases, but it's
still an operational nightmare and all you're getting out of ENUM is a
standardized database format.

You have here a very real problem that is exactly analogous to the
IP-level route-peering problem. Many years of working this problem at
the IP level have shown that statically provisioned databases (aka DNS)
are NOT an effective way to solve the problem at a large scale. DNS
provides a nice mechanism for turning a name (or phone number) into a
target IP address, but a lousy mechanism for telling us each of the
intermediate hops needed to get from a source IP address to a target IP
address (which is a vector of the router in between the two addresses).

--

Dean

---

From: Adam Roach <[email-masked]>
Date: Wed, 03 Mar 2010 15:42:42 -0600

> protocols to solve the general problem.

So, what, like TRIP, but for things other than phone numbers?

/a

---

From: David Schwartz <[email-masked]>
Date: Thu, 4 Mar 2010 01:57:02 +0200

In the now expired draft-kaplan-drinks-lrf-requirements-00, Hadriel seemed to be pushing for a "Session Location Routing Protocol" (SLRP) to deal with this issue...
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adam Roach [[email-masked]]
Sent: Wednesday, March 03, 2010 11:42 PM
To: Dean Willis
Cc: [email-masked]'
Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

/a

---

From: Daryl Malas <[email-masked]>
Date: Wed, 3 Mar 2010 17:01:36 -0700

Tim,

Thank you for the additional context.  I think we are in sync regarding the purposes of the draft as you indicate below.  Regarding placing a route header into a local non-ENUM database is obviously outside the scope of the draft.  If you use a local private ENUM server to add your own route header (or egress route) to the NAPTR URI, is implementation specific and up to you.  Even in this implementation specific case, I believe defining a best practice for defining and including egress information in the NAPTR URI will provide better industry adoption and implementation consistency.  Do you agree?

Regards,

Daryl

________________________________
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Wednesday, March 03, 2010 4:34 PM
To: Daryl Malas; PFAUTZ, PENN L (ATTCORP)
Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

Daryl,

I guess our use cases differ.

The draft illustrates a NAPTR producing a URI whose host part is the ingress point to SSP2's network through which SSP2 prefers to receive session requests targeted at the example TN.  It then talks about mechanisms to include in the ENUM response, information that "steer" the session request message through the "egress point" from SSP1's network, desired by SSP1.

I get that.  I've done it, in a private ENUM, so I know it's possible.  It's a little trickier to manage in the context of a shared registry, but still seems within the capabilities of the commercial ENUM servers with which I'm familiar.  Thinking of the "route header" solution, SSP1 could maintain in the registry a table that instructs the registry provider to append a route header identifying SBE2 to any URI whose host part was "SBE3.ssp2.example.com".  Although this sort of detail isn't subject to standardization I assume you have something like that in mind.

This seems workable in large part because SSP1 and SSP2 will in practice know quite a lot about their interconnection.  If SSP1 had no prior knowledge of the "ingress points" (e.g., SBE3) to SSP2's networks, it would be impossible to maintain such a table.  But in practice it will know these ingress points; moreover it will know how its own "egress points" are connected to them (e.g., via a partial mesh of IPsec tunnels).  Again I'm assuming you have something like this in mind.

What I meant to propose, was a different use case.  Suppose SSP2 doesn't identify its ingress point in the URI resulting from the NAPTR it returns.  Suppose instead it returns a URI whose host part is something like "call-server-1.ssp2.example.com".  This is the FQDN of the call server (e.g., softswitch, application server) in SSP2 network that will serve calls to the example TN.  Returning such a value avoids SSP2 having to make another routing decision after receiving the call from SSP1.

But if you do that, you may also want to "steer" the session request to an ingress point (SBE3 in the draft).  This could be done using e.g., a ROUTE header imbedded in the URI in the NAPTR.  The logic to determine the content of this ROUTE header is simple since it depends only on where the call is going not where it came from; and easily administered since it would be specified by the same entity that serves the example TN.

SSP1 might also want to steer the call through SBE2, which could be done via any of the mechanisms in the draft, or via some table maintained outside of ENUM.

The 2 approaches are AFAIK both possible with existing standards and supportable by currently available products.  Were it up to me, based on my current (probably flawed and incomplete) understanding, I'd probably do the former (identification of the "ingress point" to the serving domain) in the ENUM database or registry, and the latter (identification of the "egress point" from the querying domain, as a function of the URI returned in an ENUM response) either via some non-ENUM database, or via some "private data" in my local ENUM servers (private meaning not managed by the registry service).

Anyway I appreciated and enjoyed the draft, and appreciate the technical exchange.

Best regards,

Tim

________________________________
From: Daryl Malas [mailto:[email-masked]]
Sent: Wednesday, March 03, 2010 3:45 PM
To: Dwight, Timothy M (Tim); PFAUTZ, PENN L (ATTCORP)
Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

Tim,

SSP2 does provide their preferred "ingress point."  This information is still in the ENUM response regardless of whether an additional egress route variable has been added or not.

I am not sure I understand your second paragraph.

Regards,

Daryl

________________________________
From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
Sent: Wednesday, March 03, 2010 12:25 PM
To: Daryl Malas; PFAUTZ, PENN L (ATTCORP)
Subject: RE: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00
Why not let SSP2 provide their preferred "ingress point" for session requests addressed to the queried TN, in the ENUM response?  That would presumably be the same for all querying networks, and it is data for which the SSP serving the queried TN (SSP2) is authoritative.

In the common case of "mated peering points" (e.g., a pair of SBCs in SSP1 connected to a pair of SBCs in SSP2 via IPsec) SSP2 could keep a local table mapping the remote-network ingress points received in ENUM responses, to its own egress points (i.e., its SBCs that are connected via IPsec to the ingress point in the ENUM response).

tim

Sent: Wednesday, March 03, 2010 12:01 PM

Penn,

Regards,

Daryl

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

Penn,

Regards,

Daryl

Thanks,

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

All,

Regards,

Daryl

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 3 Mar 2010 20:38:33 -0500

Dean ..again this is not about _THE_ DNS only the use of DNS _technology_ to
provide a specific and necessary function for inter carrier routing as Penn
points out in the GSMA case. ENUM has difficulty in actually performing some
of these functions since the ENUM query has no way to signal what is the
source of the query since in many cases you need a differentiated response
which you correctly point out is not THE DNS as we commonly understand it.

Hadriel Kaplan put out a draft some time ago on source URI that would fix
that issue,  one I fully support.

http://ietfreport.isoc.org/all-ids/draft-kaplan-enum-source-uri-00.txt 

In some cases SIP redirect actually works better since the From: field can
allow the localized directory servers ( aka IP SCP's) to formulate a
response based on the source.

The meta issue all of these drafts are all of the lovely number translation
tasks that inspired my favorite NO TCAP NO SS7 baseball caps I made upyears
ago along with NO PRI T-shirts.

If you want to replace the PSTN you have to deal with TCAP replecemenmt and
the tools we have are ENUM and SIP and they both work. This also relates to
E.164 metadata like SPID's etal that will be addressed in the E2M BOF that
you and Bernie are running and BTW yes SIP needs a means to express non
routable E.164 metadata as well.

Any ideas on a new header for that problem?  Could you do that in a 302 MOVE
as well? 

And as for TRIP ..been there heard that argument before ..no one is going to
deploy a BGP like function for this. Not going to happen no more stacks in
the proxy's we need to deal with the protocols we have not try and invent
new ones.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adam Roach
Sent: Wednesday, March 03, 2010 4:43 PM
To: Dean Willis
Cc: [email-masked]'
Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

/a

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 4 Mar 2010 09:38:39 -0500

I think that these discussions that focus on some macro level principles that underlay the worldwide DNS system, and that seem to presume that the underlying implementation of this draft will live in plain vanilla DNS/bind implementations, out on the world-wide domain name system are not necessarily relevant.  It's certainly true that vanilla DNS and bind, as they live in the world-wide DNS system, were designed primarily to return the same answer to all queriers, and to use TTL to improve performance via caching, and generally have comparatively simple internal data structures to house their data, etc, etc.  But I do not think that is the context within which this draft is required to be used or evaluated, nor is that the context within which many many ENUM capable implementations are designed/built/used.

When you get down to it, ENUM is really just a query/response protocol for the resolution activities, and implementing an application that can give standards based ENUM responses does not require that that implementation be Bind-like in its additional capabilities and design, or that the usage context be the world-wide DNS system, or that the internal data structure just be a list of domain names with a link to a set of RRs, or that TTL/caching must always play a significant role in scalability or performance, or that responses must always be the same regardless of the querier.

Ken

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Wednesday, March 03, 2010 2:30 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

And this part right here is exactly why the DNS infrastructure of ENUM is NOT a good solution for the problem. Unlike Einstein, DNS does not embrace relativity (AKA location-context sensitivity). There are ugly hacks to make relativity happen in certain limited cases, but they defeat the fundamental scalability mechanisms of the DNS.

--
Dean

________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: Dean Willis <[email-masked]>
Date: Thu, 4 Mar 2010 10:15:45 -0600

> So, what, like TRIP, but for things other than phone numbers?

Yep. Imagine a TRIP extended to say "I have a SIP peering agreement  
with domain X". Or better yet, imagine something that actually works  
and is widely implemented that allows sharing such route information.

A caveat: we also have simple phone-number-peering issues, and TRIP  
hasn't caught on there. Therefore, I suspect that TRIP isn't quite  
right. A thorough post-mortem analysis might be interesting.

--
Dean

---

From: Daryl Malas <[email-masked]>
Date: Thu, 4 Mar 2010 10:12:07 -0700

Tim,

Personally, I think the question of how the information if uniquely conveyed to each individual SSP is an implementation issue.  I have seen it work in different methods.  My may concern with the draft is to create uniformity in how the information is conveyed to the SIP/ENUM agent.

Regards,

Daryl

Sent: Wednesday, March 03, 2010 9:08 PM

Daryl,

I agree that defining a best practice often has the impact you suggest.

IMHO the technique you describe has merit.  What's not clear is how a different response is generated per querying domain.  The draft shows response formats that would be appropriate for SSP1, but not appropriate for any other domain.  This implies that the response would be somehow tailored for each querying domain.  I think some elaboration on how that works (e.g., what has to be provisioned, by whom, to make it happen) would be helpful.

tim

Sent: Wednesday, March 03, 2010 6:02 PM

Tim,

Thank you for the additional context.  I think we are in sync regarding the purposes of the draft as you indicate below.  Regarding placing a route header into a local non-ENUM database is obviously outside the scope of the draft.  If you use a local private ENUM server to add your own route header (or egress route) to the NAPTR URI, is implementation specific and up to you.  Even in this implementation specific case, I believe defining a best practice for defining and including egress information in the NAPTR URI will provide better industry adoption and implementation consistency.  Do you agree.

Regards,

Daryl

Best regards,

Tim

Tim,

Regards,

Daryl

tim

Penn,

Regards,

Daryl

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

Penn,

Regards,

Daryl

Thanks,

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

All,

Regards,

Daryl

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 04 Mar 2010 04:08:09 +0000

Daryl,

IMHO the technique you describe has merit.  What's not clear is how a
different response is generated per querying domain.  The draft shows
response formats that would be appropriate for SSP1, but not appropriate
for any other domain.  This implies that the response would be somehow
tailored for each querying domain.  I think some elaboration on how that
works (e.g., what has to be provisioned, by whom, to make it happen)
would be helpful.

tim

Tim,

Thank you for the additional context.  I think we are in sync regarding
the purposes of the draft as you indicate below.  Regarding placing a
route header into a local non-ENUM database is obviously outside the
scope of the draft.  If you use a local private ENUM server to add your
own route header (or egress route) to the NAPTR URI, is implementation
specific and up to you.  Even in this implementation specific case, I
believe defining a best practice for defining and including egress
information in the NAPTR URI will provide better industry adoption and
implementation consistency.  Do you agree.

Regards,

Daryl

Daryl,

The draft illustrates a NAPTR producing a URI whose host part is the
ingress point to SSP2's network through which SSP2 prefers to receive
session requests targeted at the example TN.  It then talks about
mechanisms to include in the ENUM response, information that "steer" the
session request message through the "egress point" from SSP1's network,
desired by SSP1.

I get that.  I've done it, in a private ENUM, so I know it's possible.
It's a little trickier to manage in the context of a shared registry,
but still seems within the capabilities of the commercial ENUM servers
with which I'm familiar.  Thinking of the "route header" solution, SSP1
could maintain in the registry a table that instructs the registry
provider to append a route header identifying SBE2 to any URI whose host
part was "SBE3.ssp2.example.com".  Although this sort of detail isn't
subject to standardization I assume you have something like that in
mind.

This seems workable in large part because SSP1 and SSP2 will in practice
know quite a lot about their interconnection.  If SSP1 had no prior
knowledge of the "ingress points" (e.g., SBE3) to SSP2's networks, it
would be impossible to maintain such a table.  But in practice it will
know these ingress points; moreover it will know how its own "egress
points" are connected to them (e.g., via a partial mesh of IPsec
tunnels).  Again I'm assuming you have something like this in mind.

What I meant to propose, was a different use case.  Suppose SSP2 doesn't
identify its ingress point in the URI resulting from the NAPTR it
returns.  Suppose instead it returns a URI whose host part is something
like "call-server-1.ssp2.example.com".  This is the FQDN of the call
server (e.g., softswitch, application server) in SSP2 network that will
serve calls to the example TN.  Returning such a value avoids SSP2
having to make another routing decision after receiving the call from
SSP1.

But if you do that, you may also want to "steer" the session request to
an ingress point (SBE3 in the draft).  This could be done using e.g., a
ROUTE header imbedded in the URI in the NAPTR.  The logic to determine
the content of this ROUTE header is simple since it depends only on
where the call is going not where it came from; and easily administered
since it would be specified by the same entity that serves the example
TN.

SSP1 might also want to steer the call through SBE2, which could be done
via any of the mechanisms in the draft, or via some table maintained
outside of ENUM. 

The 2 approaches are AFAIK both possible with existing standards and
supportable by currently available products.  Were it up to me, based on
my current (probably flawed and incomplete) understanding, I'd probably
do the former (identification of the "ingress point" to the serving
domain) in the ENUM database or registry, and the latter (identification
of the "egress point" from the querying domain, as a function of the URI
returned in an ENUM response) either via some non-ENUM database, or via
some "private data" in my local ENUM servers (private meaning not
managed by the registry service).

Anyway I appreciated and enjoyed the draft, and appreciate the technical
exchange.

Best regards,

Tim

Tim,

SSP2 does provide their preferred "ingress point."  This information is
still in the ENUM response regardless of whether an additional egress
route variable has been added or not.

Regards,

Daryl

Why not let SSP2 provide their preferred "ingress point" for session
requests addressed to the queried TN, in the ENUM response?  That would
presumably be the same for all querying networks, and it is data for
which the SSP serving the queried TN (SSP2) is authoritative.

In the common case of "mated peering points" (e.g., a pair of SBCs in
SSP1 connected to a pair of SBCs in SSP2 via IPsec) SSP2 could keep a
local table mapping the remote-network ingress points received in ENUM
responses, to its own egress points (i.e., its SBCs that are connected
via IPsec to the ingress point in the ENUM response).

tim

Penn,

Regards,

Daryl

Daryl 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

Penn,

Regards,

Daryl

Daryl:

Thanks,

Penn Pfautz

AT&T Access Management

+1-732-420-4962

All,

 

Regards,

Daryl

Daryl Malas

w - +1 303 661 3302

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 04 Mar 2010 17:38:51 +0000

Daryl,

Maybe it would be sufficient to know that there is at least one way it
could be done.  That way need not be recommended let alone mandatory.
Just a demonstration that there is some feasible way to construct the
black box that would produce the externally visible behavior the draft
describes.  That would at least address skepticism about whether it
could be built.

Ideally though I think we'd want to know more about the applicability of
the mechanism; which could either be discussed explicitly or revealed
implicitly by the nature of the "straw man" implementation.

Tim

Sent: Thursday, March 04, 2010 11:12 AM

Tim,

Personally, I think the question of how the information if uniquely
conveyed to each individual SSP is an implementation issue.  I have seen
it work in different methods.  My may concern with the draft is to
create uniformity in how the information is conveyed to the SIP/ENUM
agent.

Regards,

Daryl

Daryl,

tim

Tim,

Regards,

Daryl

Daryl,

 

Best regards,

Tim

Tim,

Regards,

Daryl

tim

Penn,

Regards,

Daryl

Daryl 

Penn Pfautz

AT&T Access Management

+1-732-420-4962

Penn,

Regards,

Daryl

Daryl:

Thanks,

Penn Pfautz

AT&T Access Management

+1-732-420-4962

All,

 

Regards,

Daryl

Daryl Malas

w - +1 303 661 3302

---

From: Daryl Malas <[email-masked]>
Date: Tue, 9 Mar 2010 09:04:52 -0700

Dean et. al,

I am thankful my draft spurred on this discussion on potentially resolving a larger issue.  With this being said, the purpose of the draft is to be a potential component of the larger solution.  I got lost on whether or not the general community understands and sees the overall value of defining an egress method, for ensuring a consistent approach between SSPs and vendors.

Regards,

Daryl 

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Thursday, March 04, 2010 9:16 AM
To: Adam Roach
Cc: Daryl Malas; [email-masked]'
Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

> So, what, like TRIP, but for things other than phone numbers?

Yep. Imagine a TRIP extended to say "I have a SIP peering agreement with domain X". Or better yet, imagine something that actually works and is widely implemented that allows sharing such route information.

A caveat: we also have simple phone-number-peering issues, and TRIP hasn't caught on there. Therefore, I suspect that TRIP isn't quite right. A thorough post-mortem analysis might be interesting.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 9 Mar 2010 11:27:58 -0600

On Mar 9, 2010, at 10:04 AM, Daryl Malas wrote:

> Dean et. al,
>
> I am thankful my draft spurred on this discussion on potentially  
> resolving a larger issue.  With this being said, the purpose of the  
> draft is to be a potential component of the larger solution.  I got  
> lost on whether or not the general community understands and sees  
> the overall value of defining an egress method, for ensuring a  
> consistent approach between SSPs and vendors.

I definitely see the need for defining a method by which to inform  
nodes inside an ITAD of egress routes from that ITAD to other domains.  
I think that most of the people who have responded on this thread  
agree that there is such a need.

We also seem to see a need for dissemination of inter-ITAD routing  
information, although we're still discussing the relationships between  
phone numbers, ITADs, and routes.

Where we have a disagreement is on mechanism. While your proposed use  
of ITAD-specific private ENUM  servers is not completely inconsistent  
with recent trends in ENUM, I have to say we've done a lot of things  
in ENUM that I don't like, and this is pushing the envelope further in  
that direction. There are a lot of people running private DNS spaces,  
too, but we haven't standardized the discovery of default routes  
within an Intranet using private DNS for very good reasons, and those  
same reasons apply to ENUM used in the same pattern. Yes, it can be  
made to work, but it creates massive operational headaches.

We have several arguments in favor of some sort of "dynamic routing  
protocol" solution or solutions. Open questions include:

1) Are different interior and exterior routing protocols (BGP vs OSPF,  
for instance) required, or can one common protocol meet the full set f  
requirements?

2) Is  a standalone protocol such as TRIP more appropriate than  
something "inside" SIP (or DNS, XMPP, whatever)? If so, does this  
apply to both interior and exterior roles?

3) Can TRIP be made to work? This has related questions about  
aggregation models, LNP access, LNP fragmentation of aggregation, etc.

4) Can inter-ITAD routing be accomplished based on number-to-ITAD  
transformations (which ENUM gives us) accompanied by a dynamic inter- 
ITAD route exchange protocol? This may also have to factor in the LNP  
problem.

5) Can we do something combining TRIP (maybe with modifications) and  
ENUM that solves the problems? If so, will anybody deploy it, or do  
they prefer striking themselves repeatedly in the face with blunt  
objects over extended periods of time?

All-in-all, this is excellent material for the sort of problem- 
exploration process that might lead to a working group.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 9 Mar 2010 12:24:59 -0600

On Mar 3, 2010, at 10:08 PM, Dwight, Timothy M (Tim) wrote:

> IMHO the technique you describe has merit.  What’s not clear is how  
> a different response is generated per querying domain.  The draft  
> shows response formats that would be appropriate for SSP1, but not  
> appropriate for any other domain.  This implies that the response  
> would be somehow tailored for each querying domain.  I think some  
> elaboration on how that works (e.g., what has to be provisioned, by  
> whom, to make it happen) would be helpful.
>

Good questions. I'm assuming (and we all know where that leads) that  
the following describes the solution as Daryl has proposed it:

SSP1 runs its own private ENUM database, which it fully manages and  
provisions using whatever tools it has available. All nodes at SSP1  
query SSP1's ENUM servers, which return responses tailored to the SSP1  
domain.

SSP2 runs its own private ENUM database, which it fully manages and  
provisions using whatever tools it has available. All nodes at SSP2  
query SSP2's ENUM servers, which return responses tailored to the SSP2  
domain.

...

SSPn runs its own private ENUM database, which it fully manages and  
provisions using whatever tools it has available. All nodes at SSPn  
query SSPn's ENUM servers, which return responses tailored to the SSPn  
domain.

Within each SSP, each querying node must be provisioned (via some  
unspecified process) to use the SSP's private enum servers.

Like private DNS, none of the private ENUM servers is queried by the  
"outside world".

Unlike private DNS the private ENUM servers also do not query the  
outside world , because SIP routing lacks the concept of a "default  
route". Essentially, we're hacking a DNS infrastructure to provide the  
routing-knowlegde that in an IP network would be provided by RIP and/ 
or DHCP. And that's what makes this much messier than private DNS,  
which is already its own world of headaches. Each external route must  
be manually provisioned into each private-enum root server.

With this proposal, each private ENUM domain maintained by an SSP is a  
completely independent name-service island, equipped with its own root  
server. Some benefit of DNS caching and zone transfer may occur, as it  
is only necessary to manually provisioning the zone files into the  
master or "primary" private-domain root server at each SSP. Secondary  
roots (once provisioned to use the correct primary) acquire zone files  
via zone transfer, and caching servers (once provisioned to use one or  
more roots) simply do a recursive lookup towards the local root and  
cache the result until its TTL expires. But one is gaining little of  
the benefit of a global name service, and the potential for ugly  
mistakes is relatively high with any faked-root DNS model.

--
Dean

---

From: Adam Uzelac <[email-masked]>
Date: Tue, 9 Mar 2010 14:48:47 -0500

The only thing I would add to Dean's comments below is:

*" ....which return responses tailored to the SSPX domain."* for the _SAME_
target destination in every "hop" through the myriad of networks.  It
doesn't really help at the end of the day. Each SSP domain will return
something different based on the source of the query, and again, it's all fo
the same target (phone number, URI, etc).

Holy complexity, Batman!

Adam Uzelac
Global Crossing

On Tue, Mar 9, 2010 at 1:24 PM, Dean Willis <[email-masked]>wrote:

> IMHO the technique you describe has merit.  What’s not clear is how a
> response formats that would be appropriate for SSP1, but not appropriate for
> any other domain.  This implies that the response would be somehow tailored
> for each querying domain.  I think some elaboration on how that works (e.g.,
> what has to be provisioned, by whom, to make it happen) would be helpful.
>
>
>
>
> Good questions. I'm assuming (and we all know where that leads) that the
> following describes the solution as Daryl has proposed it:
>
> provisions using whatever tools it has available. All nodes at SSP1 query
> SSP1's ENUM servers, which return responses tailored to the SSP1 domain.
>

> provisions using whatever tools it has available. All nodes at SSP2 query
> SSP2's ENUM servers, which return responses tailored to the SSP2 domain.
>
> ...
>
> provisions using whatever tools it has available. All nodes at SSPn query
> SSPn's ENUM servers, which return responses tailored to the SSPn domain.
>
>
> Unlike private DNS the private ENUM servers also do not query the outside
> world , because SIP routing lacks the concept of a "default route".
> Essentially, we're hacking a DNS infrastructure to provide the
> routing-knowlegde that in an IP network would be provided by RIP and/or
> DHCP. And that's what makes this much messier than private DNS, which is
> already its own world of headaches. Each external route must be manually
> provisioned into each private-enum root server.
>
> server. Some benefit of DNS caching and zone transfer may occur, as it is
> only necessary to manually provisioning the zone files into the master or
> "primary" private-domain root server at each SSP. Secondary roots (once
> provisioned to use the correct primary) acquire zone files via zone
> transfer, and caching servers (once provisioned to use one or more roots)
> simply do a recursive lookup towards the local root and cache the result
> until its TTL expires. But one is gaining little of the benefit of a global
> name service, and the potential for ugly mistakes is relatively high with
> any faked-root DNS model.
>
> --
> Dean
>
>
>

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 09 Mar 2010 22:16:26 +0100

On 09.03.2010 18:27, Dean Willis wrote:
> 
> I definitely see the need for defining a method by which to inform nodes
> inside an ITAD of egress routes from that ITAD to other domains. I think
> that most of the people who have responded on this thread agree that
> there is such a need.

Yes, there is.

> Where we have a disagreement is on mechanism. While your proposed use of
> ITAD-specific private ENUM  servers is not completely inconsistent with
> recent trends in ENUM, I have to say we've done a lot of things in ENUM
> that I don't like, and this is pushing the envelope further in that
> direction.

As I see the problem space, we're conflating two independent problems:

a) how is routing-information exchanged between SSPs?

Here we have one approach which favors registries which digest
routing-information and spit out suitable database dumps for provisioning
the SSPs boxes. The other approach is to get some real routing-protocol up
and running between SSPs (like BGP4 for IP layer 3 routing).

b) how is this routing-information conferred to the proxies/SBCs/... which
do the actual SIP message processing / forwarding?

Now, if these proxies are actually participating in a dynamic routing
protocol (or receive full dumps from a routing registry), then b) is
internal to the proxy. Just as there is no protocol for moving routes from
the BGP table of a router to the actual packet forwarding engine, this is
purely internal to the box.

If, on the other hand, some entity distinct from the actual SIP devices
handles the routing information (either by talking to a registry, or by
running a dynamic routing protocol), then the SIP device needs a protocol
to query that routing-oracle on what to do with a given call.

It seems to me that this is what ENUM is increasingly used for within SSPs.

IMHO this is the wrong protocol choice for this task.

Why?

* ENUM is a very simple DNS application. The only key to the lookup is the
destination number, the only return value is an URL. (more or less)

* If you look at a good number of recent drafts you notice that people feel
that this is not enough: they need "ID of the SIP device" or "caller-ID" in
the query, and a sh*tload of URI-parameters (trunk-id, ...) in the answer.
See draft-mayrhofer-drinks-sed-elements for further data that might need to
get stuffed into an ENUM response.

ENUM was never intended as call-control protocol where a proxy outsources
its complete routing intelligence to an external party. It's a simple
key->URI directory lookup. The LRF (RFC 3263) and the intelligence was
supposed to be within the SIP proxy.

Now, what we need here is something closer to RADIUS than to ENUM: a
protocol where the SIP device can pack up all the information it has about
the SIP INVITE into one request to the routing-oracle which then answers
with a details set of parameters (the SED) on what the stupid proxy is
supposed to do now.

Trying to expand ENUM into doing just that is bound to fail.

cheers,

otmar
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 9 Mar 2010 22:30:42 +0000

Hi Otmar, Dean, folks,
 OK -- this has hit my "respond" threshold. Long post, but (summary @ end).

I recall thinking at the time that TRIP was not right and couldn't readily
be fixed, and was unsurprised that it just faded away. Thus I am decidedly
sceptical of attempts to resuscitate what is no longer even a ripe corpse.
It's a dead horse - stop flogging and get off.

There is no such thing as an ENUM server -- there are only DNS servers.
Thus the idea of providing different answers to the same DNS query
depending on who asked is at best limited (as in "broken").
Dispatch is sure not the place for it (nor, I would have thought, is DRINKS).
Providing a "who's asking?"-dependent response is going to require some
fancy footwork with DNS messages, so it *has* to be a DNSEXT thing.

ENUM might, just possibly, be used alone under certain limited scenarios:
IF THERE ARE RELATIVELY FEW OPTIONS (say, <= 10),
 each could be put into its own NAPTR with its own rococo parameters.
 The ENUM client would use those parameters as its "local knowledge"
 to reject the ones it couldn't/shouldn't use.
Personally, I think that this is pushing ENUM a loooooong way, but YMMV.

Problem is, *any* selective query/response protocol (RADIUS, LDAP, HTTP, ...)
that gives the entire answer to any question from dumb proxies is going
to be scale/performance limited. LNP makes every single query potentially
have a different answer from every other query, so this is a BIG database
and/or each answer has to be synthesised by the server in real time.
There ARE a lot of parameters to fit into each exchange, and lots of such
exchanges (for every call). This seems to be an Apps area issue -- good luck.

Some of the DNS based alternatives seem to be trying to split the problem
into sets of different data. IIUC, the NICC proposals were sending part of
the answer, and the client was expected to use its local knowledge to
interpret those answers. That "local knowledge" would be delivered by
other means -- not by DNS. This is NOT the same as a "who's asking?"
scheme.

Is that ENUM? -- not as specified in the 3761 and (for SIP) in 3764.
Is that ENUM-like? Could be.
Don't assume that a single ENUM query delivering the whole answer is
the only way to use DNS.
I simply do not believe that there needs to be an entirely distinct and
discrete answer given for each (queriant/target number). There ARE a
limited number of egress points from within any ITAD, and providing a
hint on the egress point to use is enough, most of the time. If not,
then looking up the current address of that egress point should be
HEAVILY cached by clients (and might be authenticated/secured/slower).

Summary -- it doesn't have to be one grand unified solution (A or B or ...).
Discounting DNS or ENUM because it doesn't give the whole answer may
be shortsighted. DNS may be *part* of the solution.

all the best,
  Lawrence

---

From: Dean Willis <[email-masked]>
Date: Tue, 9 Mar 2010 22:09:39 -0600

On Mar 9, 2010, at 1:48 PM, Adam Uzelac wrote:

> " ....which return responses tailored to the SSPX domain." for the  
> _SAME_ target destination in every "hop" through the myriad of  
> networks.  It doesn't really help at the end of the day. Each SSP  
> domain will return something different based on the source of the  
> query, and again, it's all fo the same target (phone number, URI,  
> etc).
>

Even worse, the SSPX server will return a different value based not on  
the source of the query, but on the location of the SSPX server. We  
have an implicit assumption that the queries are coming from the same  
location, which is how the ENUM server manages to return locally- 
scoped answer. The server and all its knowledge are locally-scoped,  
and getting that knowledge in there is the guano in somebody else's  
batcave.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 9 Mar 2010 23:56:36 -0600

> It's a dead horse - stop flogging and get off.

TRIP was either a wong solution to a right problem, or a right  
solution to a wrong problem. Somewhere out there is something kindof  
like TRIP (and kindof NOT like TRIP) that actually solves the right  
problem.

First we have to decide what the "right problem" is, and analysis of  
the faults of TRIP is one way to work backwards to that problem  
definition.

> be shortsighted. DNS may be *part* of the solution.

I really do think that ENUM provides an excellent means for finding  
the "destination" that is ultimately responsible for a given phone  
number. What it does NOT do is find an optimal route for getting from  
the source to the destination, given all the session-border-elements  
that have to be visited in between. We do have a lot of history on  
"finding optimal routes", and approaches for doing that look more like  
TRIP than they look like ENUM. So, we need something that adds the  
missing pieces to ENUM, and that thing (or set of things) CANOOT be  
ENUM in and of themselves, because their operational model is by  
definition different from that of DNS.

Let's think about routing at the IP level. My Mac here has only one  
route, called a "default route" that gets it to my Linksys NAT-router.  
My Mac learns this route from DHCP (but if it were statically  
configured, the default route would also be statically configured, aka  
"provisioned").

The Linksys router also learns its default route via DHCP.

The next router out, however, appears to be participating in a dynamic  
routing table (I can see it sometimes makes different routing  
decisions). It's probably running OSPF within my ISP's network, and  
exchanges its static subscriber-facing routing information dynamically  
with other routers in the ISP-cloud, while learning from those routers  
about their own adjacencies.  Eventually my traffic hits the edge of  
my ISP's network, where the routers are peering with other ISPs,  
advertising and learning routes with BGP.

Notice we haven't said anything yet about DNS. That's because DNS is  
entirely separate from routing. I think I'm actually using Google's  
DNS servers at the moment, and I suspect Google really knows very  
little about the peering topology of my ISP. So when I type "http://www.ietf.org 
" into my browser, DNS translates the name into a destination address,  
and then a combination of default, interior, and exterior routing are  
used to get my request to the IETF's web server. We're not asking  
every router along the way to look up "www.ietf.org" in the DNS again.

But for call routing to work similarly, we need 1) an analog of the  
"default route", which is probably provided by conventional  
configuration and might be well described in draft-ietf-sip-outbound,  
2) a dynamic routing protocol inside the local ISP network that helps  
my traffic get routed to an egress router, and 3) a dynamic routing  
protocol that helps get the requested from my ISP's external-facing  
SBE (an "egress route" in Daryl's draft) to an "ingress" route (and  
maybe through more egress and ingress and SBEs as it moves along  
through and between peering domains. Note that each of those peering  
domains probably have their own interior routing topology with  
steering SBCs and the like.

Both 2 and 3 are "something vaguely like TRIP" that is NOT TRIP. But  
I'd really like to concentrate on what they are, without everybody  
popping up and saying "You can't have a dynamic routing protocol  
because TRIP failed to catch on, and therefore dynamic routing  
protocols are a Bad Idea and we must instead rely on static  
configuration for everything."

--
Dean

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 10 Mar 2010 11:35:41 +0100

Lawrence,

> be shortsighted. DNS may be *part* of the solution.

As I see it, DNS/ENUM is perfect as the LUF protocol: mapping a number to
some sort of destination identifier (ITAD, Destination-Group,
Destination-Doamin, ...). This is largely independent of who's asking and
perfectly suited for DNS' delegation hierarchy and caching architecture.

The problem starts when you add the LRF: feeding that function could be
static configuration (simple leaf SSPs), simple fallback routing (leaf SSP
with two upstreams), or a full-blown routing protocol keying off the LUF's
result (ITAD, DG, ... see above).

As long as the LRF is colocated with the SIP proxy, then we just need that
routing protocol in addition to ENUM as LUF. If it isn't (the SIP proxy is
dumb and needs to ask some routing oracle what do to), then we have
basically two choices:

a) the SIP proxy could still do LUF itself, and then ask the routing oracle
how to process a call to a given destination group.

b) the SIP proxy doesn't even do the LUF itself and asks the routing oracle
what to do with a call to a given E.164 number.

--------

If one were to do a), then this would be open to various caching
optimizations. The draft that sparked this discussion tries to strong-arm
ENUM into doing b).

That is IMHO a bad idea.

otmar

---

From: Daryl Malas <[email-masked]>
Date: Wed, 10 Mar 2010 09:24:00 -0700

Dean,

One of the challenges is at what layer the information is routed.  Using your example below, after the FQDN is converted into an IP address, your Mac now routes the payload entirely through "layer 1-3" elements to reach the destination server.  With SIP, it should be considered, after the FQDN for the domain is converted into an IP address it is routed through "layer 1-3" elements to a "layer 5" element, which is not the destination.  Our existing routing protocols (e.g. RIP (just wanted to throw this one in), OSPF, BGP, etc.) focus on layer 3.  The address space and the ability to summarize this space is well understood and defined in the industry.  I think the reason we are struggling with varying solutions, whether it is TRIP or ENUM or whatever, is because we are working in an undefined address space, leveraging multiple layers.

Even if I am able to dynamically exchange domain names with other peers, so I can do my ENUM look-up, resolve to a URI, and then do a DNS look-up on the URI domain; I am still faced with layer 3 potentially routing me non-optimally to my next layer 5 hop.  The reason for this is, simply, my layer 3 routers are not layer 5 aware.  I either statically define layer 3 or layer 5, but these are the only two options I see at this point.

The other thing to consider is layer 5 providers (SSPs), in my perception, are far more paranoid than layer 3 providers (SPs).  I believe this is the perception of the redundant, redundant, diversified, diversified super duper extra stable telephony infrastructure that was built over a 100 years.  In another 60 years, SPs will be the same as IP is leveraged more and more for "time sensitive" applications.

Regards,

Daryl

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Tuesday, March 09, 2010 10:57 PM
To: Lawrence Conroy
Cc: [email-masked]
Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

TRIP was either a wong solution to a right problem, or a right solution to a wrong problem. Somewhere out there is something kindof like TRIP (and kindof NOT like TRIP) that actually solves the right problem.

First we have to decide what the "right problem" is, and analysis of the faults of TRIP is one way to work backwards to that problem definition.

...

I really do think that ENUM provides an excellent means for finding the "destination" that is ultimately responsible for a given phone number. What it does NOT do is find an optimal route for getting from the source to the destination, given all the session-border-elements that have to be visited in between. We do have a lot of history on "finding optimal routes", and approaches for doing that look more like TRIP than they look like ENUM. So, we need something that adds the missing pieces to ENUM, and that thing (or set of things) CANOOT be ENUM in and of themselves, because their operational model is by definition different from that of DNS.

Let's think about routing at the IP level. My Mac here has only one route, called a "default route" that gets it to my Linksys NAT-router. My Mac learns this route from DHCP (but if it were statically configured, the default route would also be statically configured, aka "provisioned").

The next router out, however, appears to be participating in a dynamic routing table (I can see it sometimes makes different routing decisions). It's probably running OSPF within my ISP's network, and exchanges its static subscriber-facing routing information dynamically with other routers in the ISP-cloud, while learning from those routers about their own adjacencies.  Eventually my traffic hits the edge of my ISP's network, where the routers are peering with other ISPs, advertising and learning routes with BGP.

Notice we haven't said anything yet about DNS. That's because DNS is entirely separate from routing. I think I'm actually using Google's DNS servers at the moment, and I suspect Google really knows very little about the peering topology of my ISP. So when I type "http://www.ietf.org" into my browser, DNS translates the name into a destination address, and then a combination of default, interior, and exterior routing are used to get my request to the IETF's web server. We're not asking every router along the way to look up "www.ietf.org<http://www.ietf.org>" in the DNS again.

But for call routing to work similarly, we need 1) an analog of the "default route", which is probably provided by conventional configuration and might be well described in draft-ietf-sip-outbound, 2) a dynamic routing protocol inside the local ISP network that helps my traffic get routed to an egress router, and 3) a dynamic routing protocol that helps get the requested from my ISP's external-facing SBE (an "egress route" in Daryl's draft) to an "ingress" route (and maybe through more egress and ingress and SBEs as it moves along through and between peering domains. Note that each of those peering domains probably have their own interior routing topology with steering SBCs and the like.

Both 2 and 3 are "something vaguely like TRIP" that is NOT TRIP. But I'd really like to concentrate on what they are, without everybody popping up and saying "You can't have a dynamic routing protocol because TRIP failed to catch on, and therefore dynamic routing protocols are a Bad Idea and we must instead rely on static configuration for everything."

--
Dean

---

From: Daryl Malas <[email-masked]>
Date: Wed, 10 Mar 2010 16:16:09 -0700

Dean,

Based on your assessment below, let me try and summarize:

Two IETF efforts:
1) Egress Route Method for SIP (Intra-domain)
2) Dynamic Routing Method for SIP (Inter-domain)

I attempted to provide my response to your questions below.

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Tuesday, March 09, 2010 10:28 AM
To: Daryl Malas
Cc: Adam Roach; [email-masked]
Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

On Mar 9, 2010, at 10:04 AM, Daryl Malas wrote:

> lost on whether or not the general community understands and sees the 
> overall value of defining an egress method, for ensuring a consistent 
> approach between SSPs and vendors.

I definitely see the need for defining a method by which to inform nodes inside an ITAD of egress routes from that ITAD to other domains.  
I think that most of the people who have responded on this thread agree that there is such a need.

We also seem to see a need for dissemination of inter-ITAD routing information, although we're still discussing the relationships between phone numbers, ITADs, and routes.

Where we have a disagreement is on mechanism. While your proposed use of ITAD-specific private ENUM  servers is not completely inconsistent with recent trends in ENUM, I have to say we've done a lot of things in ENUM that I don't like, and this is pushing the envelope further in that direction. There are a lot of people running private DNS spaces, too, but we haven't standardized the discovery of default routes within an Intranet using private DNS for very good reasons, and those same reasons apply to ENUM used in the same pattern. Yes, it can be made to work, but it creates massive operational headaches.

We have several arguments in favor of some sort of "dynamic routing protocol" solution or solutions. Open questions include:

1) Are different interior and exterior routing protocols (BGP vs OSPF, for instance) required, or can one common protocol meet the full set f requirements?
[DM] Good question.  I think we need to have one that works for either before we can determine whether it is internal for external only.

2) Is  a standalone protocol such as TRIP more appropriate than something "inside" SIP (or DNS, XMPP, whatever)? If so, does this apply to both interior and exterior roles?
[DM] After some "hallway collaboration," I do not think TRIP will work, at all, in it's current state.

3) Can TRIP be made to work? This has related questions about aggregation models, LNP access, LNP fragmentation of aggregation, etc.
[DM] Maybe; but whether you use domains or E.164 addresses, the underlying layer 3-to-layer 5 issues still exists.

4) Can inter-ITAD routing be accomplished based on number-to-ITAD transformations (which ENUM gives us) accompanied by a dynamic inter- ITAD route exchange protocol? This may also have to factor in the LNP problem.
[DM] I think this may be a more likely potential, but still has a lot of issues in forming the routing table.  A lot of dissegrated user information will cause a very large routing table.  Using domains for the routing table may be an option.  I am not sure what value this provides over existing ENUM solutions, though.  Creating another solution for the same problem does not always make for a more efficient solution.  It may just create another solution, which will cause industry fragmentation in implementation preferences.

5) Can we do something combining TRIP (maybe with modifications) and ENUM that solves the problems? If so, will anybody deploy it, or do they prefer striking themselves repeatedly in the face with blunt objects over extended periods of time?
[DM] I worked through this scenario on a whiteboard for 30 minutes or so, and I struggled to see any resolution to the problems.  It just makes it more complicated in a different way.

All-in-all, this is excellent material for the sort of problem- exploration process that might lead to a working group.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 Mar 2010 17:46:07 -0600

On Mar 10, 2010, at 10:24 AM, Daryl Malas wrote:

> Dean,
>
> One of the challenges is at what layer the information is routed.   
> Using your example below, after the FQDN is converted into an IP  
> address, your Mac now routes the payload entirely through "layer  
> 1-3" elements to reach the destination server.  With SIP, it should  
> be considered, after the FQDN for the domain is converted into an IP  
> address it is routed through "layer 1-3" elements to a "layer 5"  
> element, which is not the destination.  Our existing routing  
> protocols (e.g. RIP (just wanted to throw this one in), OSPF, BGP,  
> etc.) focus on layer 3.  The address space and the ability to  
> summarize this space is well understood and defined in the  
> industry.  I think the reason we are struggling with varying  
> solutions, whether it is TRIP or ENUM or whatever, is because we are  
> working in an undefined address space, leveraging multiple layers.

I agree. Further, what I think that we're doing is trying to build an  
applicational-level routing later that is structurally similar to the  
IP routing layer, but operates on this other address space. It's a  
classic example of an overlay network.

"Names" are the next-level addresses. HIP and other locator-identifier  
separators are structurally very similar to what we're talking about  
doing with "domains" and "ITAD identifiers".

>
> Even if I am able to dynamically exchange domain names with other  
> peers, so I can do my ENUM look-up, resolve to a URI, and then do a  
> DNS look-up on the URI domain; I am still faced with layer 3  
> potentially routing me non-optimally to my next layer 5 hop.  The  
> reason for this is, simply, my layer 3 routers are not layer 5  
> aware.  I either statically define layer 3 or layer 5, but these are  
> the only two options I see at this point.

RIght. What I think we've been fumbling toward is a dynamic Layer 5  
routing fabric that itself is Layer 3 aware, and therefore handles

>
> The other thing to consider is layer 5 providers (SSPs), in my  
> perception, are far more paranoid than layer 3 providers (SPs).  I  
> believe this is the perception of the redundant, redundant,  
> diversified, diversified super duper extra stable telephony  
> infrastructure that was built over a 100 years.  In another 60  
> years, SPs will be the same as IP is leveraged more and more for  
> "time sensitive" applications.

We could have done what we needed to with RSVP, but the Net wasn't  
ready for resolving conflicts between real-time flows yet. In one  
possible future, everything on the Net that is real-time constrained  
has something like RSVP assuring its timeliness. In another, the "open  
Internet" is gone, replaced by lots of different application-level  
routing fabrics running over dedicated layer 3 that is over  
provisioned to handle it. I don't see a happy middle ground.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 Mar 2010 17:48:13 -0600

> 2) Dynamic Routing Method for SIP (Inter-domain)

It's possible both could be done by one protocol, possibly with two  
modes of operation.

--
Dean

---

From: Greger Viken Teigre <[email-masked]>
Date: Fri, 12 Mar 2010 08:18:47 +0100

> It's possible both could be done by one protocol, possibly with two 

I think you're onto something here. A few observations from the context 
of business-quality video conferencing/telepresence (some may be on a 
tangent, but as a different perspective on related problems):

Even within an enterprise network, there may be different administrative 
domains. E.164 numbers are starting to become really difficult to manage 
as geography is less relevant when the clients roam. Due to this and 
because of an increasing number of SIP-based non-PSTN services that 
connect into the voice-fabric of the enterprise (presence federation, 
hunt groups across voice, video, PC client), more and more a 
domain-based routing model are mixed with the traditional e.164 dial 
plan. If you do a 4Mb/s video call, choosing the right egress point from 
one administrative domain to another or towards a peering 
partner/service provider becomes critical due to the bandwidth 
requirements and need for a capable client at the other end. Choosing 
the right egress can actually influence whether the call goes through at 
all (or end up as voice only, when yuo could have had video).

We see more and more mixed environments where SIP clients either 
register to or send SIP messages over other vendors' SIP servers. If the 
call is routed (or forked) to multiple destinations, you can never be 
sure that you actually get the "best" result (as in get to the callee 
client with the most compatible functionality), and in fact, often the 
call will fail because you may get a quicker response from a 
less-capable network/device, it attempts to take the call with a 200 OK 
(or maybe Not supported here) and then something fails due to 
incompatibilities in SDP. There is not only a question of choosing the 
right egress, but when you move outside your domain, you don't have any 
control, so the problem becomes bigger.

As a service provider offering connectivity to the enterprise, there is 
no good way to plan the egress together with the enterprise. A 4 Mb/s 
video call may be attempted over a SIP trunk not capable of a video call 
(e.g. local branch office in one country), while the same call could 
have been successfully forwarded through the main office in another 
country. Well, you tell the user: you used the wrong URI or number. Or 
the hunt group was configured with wrong priorities.  Why should the 
user care?

Then once in the service provider's network, the calls have a tendency 
to use e.164 numbers (because that's what the service provider "likes") 
with a domain that sometimes seems to be accidental. If the call is a 
PSTN call, it's much cheaper to route the call over the old 
interconnects, but if it's a 4Mb/s video call, you may want to route 
over another peering fabric for video. You can solve that by separating 
voice and video (which is mostly done as video often is over the data 
network) and the address space so that the routing decision is really 
left to the user.

Some of these examples have multiple problems in them, but following the 
discussion, I have been a bit worried that the focus on fixing a problem 
for service providers doing regular voice calls and solving it with ENUM 
will make us forget that there are some other related problems that are 
looming in the not so distant future. I am therefore happy that the 
focus has shifted a bit towards solving the generic problem.

And BTW, the problems are not really only video-focused. If you want to 
peer HD voice traffic, you need a way to filter out the e.164 numbers 
you can route over an HD-capable peering network, while the remaining 
calls go the cheap route. The typical resolution I have seen is to set 
up an ENUM service. I haven't really seen how this can scale to using 
URIs, and to a complex set of capabilities (IM, presence, video of 
different flavors...)
g-)

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Mar 2010 10:48:07 -0500

Greger:

For what it's worth, RFCs 3840 and 3841 (caller prefs/callee caps) 
provide about 80% of what you're asking for.

/a

On 3/12/10 01:18, Mar 12, Greger Viken Teigre wrote:
> Even within an enterprise network, there may be different 
> administrative domains. E.164 numbers are starting to become really 
> difficult to manage as geography is less relevant when the clients 
> roam. Due to this and because of an increasing number of SIP-based 
> non-PSTN services that connect into the voice-fabric of the enterprise 
> (presence federation, hunt groups across voice, video, PC client), 
> more and more a domain-based routing model are mixed with the 
> traditional e.164 dial plan. If you do a 4Mb/s video call, choosing 
> the right egress point from one administrative domain to another or 
> towards a peering partner/service provider becomes critical due to the 
> bandwidth requirements and need for a capable client at the other end. 
> Choosing the right egress can actually influence whether the call goes 
> through at all (or end up as voice only, when yuo could have had video).
>
> register to or send SIP messages over other vendors' SIP servers. If 
> the call is routed (or forked) to multiple destinations, you can never 
> be sure that you actually get the "best" result (as in get to the 
> callee client with the most compatible functionality), and in fact, 
> often the call will fail because you may get a quicker response from a 
> less-capable network/device, it attempts to take the call with a 200 
> OK (or maybe Not supported here) and then something fails due to 
> right egress, but when you move outside your domain, you don't have 
> any control, so the problem becomes bigger.
>
> As a service provider offering connectivity to the enterprise, there 
> is no good way to plan the egress together with the enterprise. A 4 
> Mb/s video call may be attempted over a SIP trunk not capable of a 
> video call (e.g. local branch office in one country), while the same 
> call could have been successfully forwarded through the main office in 
> another country. Well, you tell the user: you used the wrong URI or 
> number. Or the hunt group was configured with wrong priorities.  Why 
> should the user care?
>
> to use e.164 numbers (because that's what the service provider 
> "likes") with a domain that sometimes seems to be accidental. If the 
> call is a PSTN call, it's much cheaper to route the call over the old 
> over another peering fabric for video. You can solve that by 
> separating voice and video (which is mostly done as video often is 
> over the data network) and the address space so that the routing 
> decision is really left to the user.
>
> Some of these examples have multiple problems in them, but following 
> the discussion, I have been a bit worried that the focus on fixing a 
> problem for service providers doing regular voice calls and solving it 
> with ENUM will make us forget that there are some other related 
> problems that are looming in the not so distant future. I am therefore 
> happy that the focus has shifted a bit towards solving the generic 
> problem.
>
> And BTW, the problems are not really only video-focused. If you want 
> to peer HD voice traffic, you need a way to filter out the e.164 
> numbers you can route over an HD-capable peering network, while the 
> remaining calls go the cheap route. The typical resolution I have seen 
> is to set up an ENUM service. I haven't really seen how this can scale 
> to using URIs, and to a complex set of capabilities (IM, presence, 
> video of different flavors...)
> g-)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Mar 2010 12:09:02 -0400

> provide about 80% of what you're asking for.

Selecting a *UAS* that has the capabilities the caller envisions using 
(such as video) were certainly among the things that were among the 
intended use cases.

I'm dubious about their suitability for selecting a route to reach the 
UAS, assuming its the same UAS you are seeking.

Also callerprefs are no guarantee (not even a superset) of the 
capabilities that will be used on a call. It is an entirely reasonable 
use case for a UAC to invite with no offer, and then negotiate the use 
of voice and video because the UAS offers that. Its also entirely 
reasonable for a call to start out as audio only, for the caller and 
callee to learn as a result of discussion that both are video capable, 
and then add video to the call.

As non-voice media become more mainstream, and as e2e sip sessions 
become more feasible, we should be investigating how the infrastructure 
can avoid breaking these kinds of use cases. Nailing down the route in a 
way that precludes use of media not announced at call establishment time 
isn't going in a very helpful direction.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Mar 2010 11:24:39 -0500

> UAS, assuming its the same UAS you are seeking.

That's the other 20%. :)

> become more feasible, we should be investigating how the 
> infrastructure can avoid breaking these kinds of use cases. Nailing 
> down the route in a way that precludes use of media not announced at 
> call establishment time isn't going in a very helpful direction.

Nailing down a route... for signaling? I'm a bit confused about how that 
is going to preclude certain media types.

Now, if we want to talk about media steering, that's a completely 
different issue. I don't think SIP routing plays into that.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Mar 2010 12:33:48 -0400

>> UAS, assuming its the same UAS you are seeking.

I think we're following the 80/80 rule here. :-)

> different issue. I don't think SIP routing plays into that.

Perhaps I misinterpreted the draft, but I got the distinct impression 
that media steering, following the signaling path, was presumed, and the 
primary issue being raised.

Hence my concern.

	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Mar 2010 12:33:20 -0500

On 3/15/10 11:33, Mar 15, Paul Kyzivat wrote:
>
> Adam Roach wrote:
>> Nailing down a route... for signaling? I'm a bit confused about how 
>> that is going to preclude certain media types.
>>
> that media steering, following the signaling path, was presumed, and 
> the primary issue being raised.

And, to be clear, that's probably what Daryl has in mind. But it doesn't 
sound like what Greger is trying to do.

Daryl is working within the strictures of reproducing the business 
relationships of the PSTN in a SIP network. And the path that has been 
taken, for better or worse, involves the heavy use of SBCs and other 
devices that impose a rather strict control on the way things are done. 
These devices largely ensure that the media path follows the signaling 
path, even when that's not the optimal thing to do. The chances of such 
networks deploying video, hi-def voice, or any of the other really neat 
things that Greger mentions are slim to none. This, of course, is NOT 
Daryl's fault. But it's where the egress-route work comes from.

Greger is speaking more towards the network you seem to have in mind -- 
one in which end-to-end SIP calls are possible, without SBCs or similar 
control boxes clobbering new services and mangling the ability to convey 
novel media from one endpoint to another. Networks where we don't need 
to define alternate connection models for protocols simply to 
accommodate network elements that do things that are explicitly 
disallowed by protocol specification.

Don't get me wrong -- the business concerns driving SBC deployment are 
legitimate. But that doesn't change the fact that they destroy innovation.

In many ways, these approaches represent an unfortunate bifurcation in 
the SIP road. One path leads to a rather stagnant network that manages 
to reproduce what we've been doing for the past century, possibly with 
some minor operational cost savings. The other leads to vibrant new 
services, end-to-end multimedia, and innovative applications.

But that fork has already been taken, and I don't think we're going to 
join the paths back again any time soon. So, for the time being, we find 
ourselves doing work in the stagnant world (SPEERMINT, MARTINI, DRINKS) 
as well as the vibrant world (P2PSIP, SIP Certs, CODEC). And, while 
there can be some commonality between solutions, the increasing 
difficulty that people in the two different worlds have acknowledging 
the other makes it nearly impossible to come up with solutions that make 
everyone happy.

The constituents of the stagnant world will find any vibrant solutions 
to be too complicated, too general, and subject to being broken by their 
intermediaries. The constituents of the vibrant world will find any 
stagnant solutions to be too brittle, too special-purpose, and too 
constrained.

Getting back to the problem at hand.

In the stagnant world, steering the signaling effectively steers the 
media. And if you can combine that steering with E.164-number lookup 
(because the stagnant world uses phone numbers), then the problem is 
solved. Anything more general is going to be too complicated, too 
general, and subject to be broken by SBCs.

In the vibrant world, signaling and media follow different paths. 
Steering the signaling is unlikely to change the media path. If you want 
to steer media, you would need to do so explicitly. We already have some 
mechanisms defined in the RAI area to do this -- TURN comes to mind -- 
and there are probably others at layer 3 that I'm not familiar with. 
This is where we may need some new work. Anything that requires E.164 
numbers as identifiers or that assumes media follows the signaling path 
is going to be too brittle, too special purpose, and too constrained.

Which is to say that I don't think there is a solution that satisfies 
both groups. The divergence from the fork between the stagnant world and 
the vibrant world is great enough that there is no common ground left 
for these kinds of issues. As odious as it is, I'm afraid we're stuck 
with solving this problem twice. The real challenge is ensuring that 
stagnant solutions don't do lasting damage to the core protocols -- we 
need to make sure they don't destroy the vibrant world with collateral 
damage.

Which is why I support a simple, non-normative, informational draft 
about the form of URLs that one might want to put in ENUM. It satisfies 
the requirements of the stagnant world, and doesn't even have any 
normative impacts on any protocol anywhere. It's harmless, and lets the 
people in the vibrant world concentrate on solving the problem in a more 
general way without having to accommodate the peculiarities of network 
elements living in the stagnant world.

/a

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Mar 2010 16:15:49 -0500

> different issue. I don't think SIP routing plays into that.

Ah, but it does.

Given the "evil peering architecture" (we really need a better  
dictionary for this) under discussion, the signaling route selected  
affects the media route, perhaps even limiting the media changes  
available once the call has been established. We're really talking  
about application-driven IP routing as an end-goal. The A-IMS model of  
using SIP to set up one's permission for using an HTTP proxy for web  
browsing is just the tip of this iceberg.

Imagine, if you will, an IP network where each router takes into  
consideration not just the destination address of a packet but all  
sorts of other information (aka "metadata") including packet source,  
application, billing relationships, current contractual quotas,  
censorship rules, and all sorts of other stuff before it chooses the  
route by which it is going to send that packet towards its next hop.

Making these routing decisions at SIP proxies is an interim step. It  
breaks the Internet up into myriad islands, each connected only by  
application gateways. IP routing as we know it is still used inside  
each island (although perhaps only on a transitional basis). But  
routing between islands is driven by more business-like (or even  
political) factors; simple route efficiency is inadequate for  
expressing the complex and shifting policy framework of the net.

The logical outgrowth of the model is that every router become both a  
policy decision and policy enforcement point, provisioned with and  
taking into account the operational and political rules that govern  
utilization. Only a tiny fraction of these rules have anything to do  
with efficient delivery of a packet from Alice to Bob. Rather, they  
include things like seeing that the application is SOX compliant,  
making sure that the appropriate watchers-and-listeners have access to  
the content, diverting widget-orders from the intended recipient  
towards an ally of the router operator's and so on. Of course,  
efficient delivery and bandwidth management is still crucial, so  
perhaps something like RSVP will be used within "islands" to separate  
the policy decisions made by the application gateways from the policy  
enforcement of packet delivery, so perhaps it won't diverge totally  
from the Internet as we know it.

Certainly this sort of system is the end-goal of very few people who  
are working on the technology today, but it is the (or at least "a")  
logical outgrowth of application-specific routing. It's what happens  
when we abandon the end-to-end principle and its related concepts of  
address-based application-independent routing, etc.

Most people aren't trying to "change the Internet".  People are just  
asking for ways to solve today's problems. Problems like "How do I  
tell my SIP nodes which SBC to use for calls to area code 212" or  
"Which NAT router should I use to reach Google most efficiently"? have  
as their basis an understanding that we've moved somewhat away from  
the Internet and towards something very different -- a route is not  
just a route, an application is not just an IP Address and a port  
number,  and no node can be trusted to handle ALL of an important  
task, because everything eventually gets hacked.

So, do we take this understanding of the difference between the common  
"real" network and the theoretical Internet and attempt to solve  
people's problems as they see them today, or do we step back and ask  
"What is the Internet way to solve this problem, why isn't it working,  
and what do we have to do to make it work right?" My guess is the  
former; it's easier, and there's more money to be made on it today. In  
the long run it destroys our world, but we just aren't geared towards  
understanding those kinds of things and would much rather just have  
today's problem fixed today.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Mar 2010 16:21:17 -0500

> Which is to say that I don't think there is a solution that  
> satisfies both groups. The divergence from the fork between the  
> stagnant world and the vibrant world is great enough that there is  
> no common ground left for these kinds of issues. As odious as it is,  
> I'm afraid we're stuck with solving this problem twice. The real  
> challenge is ensuring that stagnant solutions don't do lasting  
> damage to the core protocols -- we need to make sure they don't  
> destroy the vibrant world with collateral damage.

Beautifully said! I read it just after my similar but less-elegant  
rant, which presumes that the stagnant world is likely to be selected  
over the vibrant through the simple processes of expediency, apathy,  
corruption, greed, and fear. But then, I'm an optimist.

--
Dean

---

From: Daryl Malas <[email-masked]>
Date: Tue, 16 Mar 2010 15:59:37 -0600

I believe this issue was summarized well during the 73rd IETF meeting at the RAI open meeting, and captured in Jonathan's draft: http://tools.ietf.org/html/draft-rosenberg-rai-modest-proposal-00

I believe we MUST solve this problem twice.  Let's be realistic.  Understanding the problem fully, defining the requirements, establishing the group and hammering through the varying solutions will take 5 - 10 years to complete.  The telecommunications industry will develop their own proprietary mechanisms for doing this, creating greater fragmentation and interoperability issues; or the IETF can step up and as an interim solution say, since, you are going to solve this, do it this way.  At least in this case, we will know where the industry is at in their resolution rather than guessing at the plethora of "potentials" down the road.

Regards,

Daryl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Tuesday, March 16, 2010 3:21 PM
To: Adam Roach
Cc: [email-masked]
Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

> both groups. The divergence from the fork between the stagnant world 
> and the vibrant world is great enough that there is no common ground 
> left for these kinds of issues. As odious as it is, I'm afraid we're 
> stuck with solving this problem twice. The real challenge is ensuring 
> that stagnant solutions don't do lasting damage to the core protocols 
> -- we need to make sure they don't destroy the vibrant world with 
> collateral damage.

Beautifully said! I read it just after my similar but less-elegant rant, which presumes that the stagnant world is likely to be selected over the vibrant through the simple processes of expediency, apathy, corruption, greed, and fear. But then, I'm an optimist.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Mar 2010 17:24:52 -0600

On 3/16/10 3:59 PM, "Daryl Malas" <[email-masked]> wrote:

> I believe this issue was summarized well during the 73rd IETF meeting at the
> RAI open meeting, and captured in Jonathan's draft:
> http://tools.ietf.org/html/draft-rosenberg-rai-modest-proposal-00

I think Jonathan Rosenberg correctly identified that there was a problem
here. And then, just like Jonathan Swift's original "Modest Proposal," he
goes on to propose that the solution to our problem is best found in eating
our own children.

I disagree profoundly with characterizing Rosenberg's Modest Proposal as an
appropriate summary of the issues, as it gets the analysis precisely wrong.
It proposes completely abandoning the vibrant world as a lost cause, and
embracing the stagnant world as the only path forward. This isn't just
allowing collateral damage to the vibrant world for the sake of expediency
in stagnant world solutions -- it's a suggestion that we nuke the vibrant
world so it doesn't keep annoying people trying to develop stagnant
solutions.

I'll admit that it's easier to see the stagnant world, since the telcos have
quite a bit of money to throw around driving its deployment. But there are
people in the vibrant world working on new services. Go back and re-read
Greger's description of what he's seeing deployed. Check out the stuff that
AG Projects (http://ag-projects.com/) has been working on, selling, and
actually deploying. I don't recall whether you would have been at the
meeting where I wore a t-shirt showing some novel SIP devices -- I'll bring
it to Anaheim.

/a

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Mar 2010 17:49:45 -0500

> world so it doesn't keep annoying people trying to develop stagnant

I have long speculated that perhaps the best thing we can do is punt  
the "stagnant world" stuff to a different forum. I seem to recall many  
times suggesting that SIP should just be moved to the ITU so we can  
get on with building the Internet. I'd happily add ENUM to the same  
bucket.

The problem is that we might wake up one day and realize that the  
Internet has been turned off, and all we have left is a stagnant  
backwater of telecommunications boundaries established by fat-and- 
happy politicos eager to preserve their own domains.

The alternative, perhaps, is to embrace stagnation. Then add chlorine.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Mar 2010 18:01:05 -0500

On 3/16/10 5:49 PM, Dean Willis wrote:
> backwater of telecommunications boundaries established by 
> fat-and-happy politicos eager to preserve their own domains.

Surely you've seen what I'm trying to do here. I've spent a 
disproportionate amount of my IETF time making sure MARTINI doesn't do 
something profoundly stupid to SIP registration (which, as you point 
out, already has some broken baked into it). I'm actually agitating for 
acceptance and publication of Daryl's draft, since it's harmless and 
will hopefully prevent some other SDO from coming up with something 
that's actually dangerous.

I think doing the stagnant world things in the IETF is still the right 
answer, as painful as it is to have to continually deal with solutions 
that willfully destroy the end-to-end principle. Because doing the work 
here at least allows us to steer things into directions that cause the 
least amount of harm.

 From that perspective, Daryl's draft is perfect[1]: it doesn't actually 
create any new protocol at all.

> The alternative, perhaps, is to embrace stagnation. Then add chlorine.

The problem, of course, is not the muck. It's the fact that it's not 
moving forward. Chlorine won't make it go.

/a

[1] Assuming we don't define new DNS record types

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 16 Mar 2010 19:29:30 -0400

I'm not sure that dispatching malas-dispatch-sip-egress-route requires us to untwist this particular Gordian knot, nor to resurrect TRIP,  nor to declare some kind of interplanetary Armageddon.

I think Otmar Lendl has been right on the mark in this discussion. He points out that global directories like ENUM serve well as an LUF and poorly as an LRF, to speak in the SPEERMINT idiom - I don't think this is an especially controversial point. I read malas-dispatch-sip-egress as a document that argues that knowing the results of the LUF doesn't necessarily help you to find a next hop to route your call through. Again, I'd say not especially controversial.

malas-dispatch-sip-egress-route then goes on to specify a few NAPTR syntaxes that could contain a sort of joint LUF/LRF routing information. The only conceptual problem I have with this approach is that the entity that typically provisions the LUF doesn't know the local topology of the originating network well enough to say useful things about the LRF - that is indeed the entire motivation for considering the LUF and LRF as separate lookups. The draft sort of glosses this over with a lot of passive voice when describing how the ENUM provisioning gets done. Is it done by the terminating side, or the originating side, or somehow both?

In any event, from a DISPATCH perspective, I'd propose the problem seems to lie comfortable within the parameters of SPEERMINT. Surely one of the SPEERMINT chairs must think this is a worthwhile effort...

Jon Peterson
NeuStar, Inc.

On 3/16/10 3:24 PM, "Adam Roach" <[email-masked]> wrote:

/a

---

From: Daryl Malas <[email-masked]>
Date: Tue, 16 Mar 2010 17:50:02 -0600

Adam and Dean,

Perhaps you have misunderstood my comments.  My comment is, simply, it is better to know and control the "ugly" truths rather than simply sweep them under the rug and blindly believe they do not exist.  In this way, you know what evil you will need to face, rather than being surprised by the unknown proprietary solutions vendors have created based on monetary rather than technology gains.

Regards,

Daryl

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, March 16, 2010 5:01 PM
To: Dean Willis
Cc: Daryl Malas; [email-masked]
Subject: Re: War of the Worlds (was Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00)

> fat-and-happy politicos eager to preserve their own domains.

Surely you've seen what I'm trying to do here. I've spent a disproportionate amount of my IETF time making sure MARTINI doesn't do something profoundly stupid to SIP registration (which, as you point out, already has some broken baked into it). I'm actually agitating for acceptance and publication of Daryl's draft, since it's harmless and will hopefully prevent some other SDO from coming up with something that's actually dangerous.

I think doing the stagnant world things in the IETF is still the right answer, as painful as it is to have to continually deal with solutions that willfully destroy the end-to-end principle. Because doing the work here at least allows us to steer things into directions that cause the least amount of harm.

 From that perspective, Daryl's draft is perfect[1]: it doesn't actually create any new protocol at all.

> The alternative, perhaps, is to embrace stagnation. Then add chlorine.

The problem, of course, is not the muck. It's the fact that it's not moving forward. Chlorine won't make it go.

/a

---

From: Daryl Malas <[email-masked]>
Date: Tue, 16 Mar 2010 18:04:10 -0600

Jon,

The provisioning of the "egress route" information is done by the originating side.  The terminating side provisions their ingress routing information into an ENUM server, and the originating party evalutes the routes and associates egress routes to them.  In this way, they append the information provided by the terminating side (provisioning side).  If the terminating side changes the route (domain's) associated with the TNs, which an egress route was appended, then the egress route information is no longer valid and is removed.  The originating side would have to append a new egress route.  Yes, this may seem inefficient, but there are two industry assumptions: 1) routes do not change very often; 2) the efficiency gained by associating an egress route is greater than the inefficiency in updating egress routes.

This draft does not consider the "business" reasons for doing this, but simply says...since, we know you are already doing this, then we should make the method consistent using (a) well defined mechanism(s) approved by a body of experts.

I do not think this goes against what Otmar was asserting in his Speermint draft.  I believe Otmar was trying to address a bigger picture issue, which was not ignored in Speermint.  On the contrary, we decided early to address the short-term issue of basic telephony peering using SIP, and then move on to the bigger more complex issue.  It just took us longer to get there than we expected.  We are still listening.

Regards,

Daryl

________________________________
From: Peterson, Jon [mailto:[email-masked]]
Sent: Tuesday, March 16, 2010 5:30 PM
To: Adam Roach; Daryl Malas; Dean Willis
Cc: [email-masked]
Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00)

Jon Peterson
NeuStar, Inc.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Mar 2010 19:47:21 -0500

> Perhaps you have misunderstood my comments.  My comment is, simply, it is better to know and control the "ugly" truths rather than simply sweep them under the rug and blindly believe they do not ex…

That's exactly what I say below.

/a

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 16 Mar 2010 23:19:27 -0500

This really sums up the enigma why the IETF should do work that contradicts
every principle of the Internet architecture and its engineering.

It may be useful to remember the  _solid_   track record of the  "stagnant
world"
* OSI 
* X4.00 mail 
* IN 
* AIN 
* ISDN 
* SONET/SDH 
* ATM 
* BISDN 
* H.323 
* current re-incarnations such as PSTN/SIP and other (avoiding flames
here)...
How many companies have disappeared building this stuff? Layoffs. Capital
destruction.

The other enigma is the tolerance to associate the IETF with the
reincarnations of these failures.

>I have long speculated that perhaps the best thing we can do is punt the
"stagnant world" stuff to a different forum.
>I seem to recall many times suggesting that SIP should just be moved to the ITU
so we can get on with building the Internet.
>I'd happily add ENUM to the same bucket.

Well said.

Thanks, Henry

On 3/16/10 5:49 PM, "Dean Willis" <[email-masked]> wrote:

> I have long speculated that perhaps the best thing we can do is punt the
> "stagnant world" stuff to a different forum. I seem to recall many times
> suggesting that SIP should just be moved to the ITU so we can get on with
> building the Internet. I'd happily add ENUM to the same bucket.
> 
> The problem is that we might wake up one day and realize that the Internet has
> been turned off, and all we have left is a stagnant backwater of
> telecommunications boundaries established by fat-and-happy politicos eager to
> preserve their own domains.
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 17 Mar 2010 00:34:02 -0500

On Mar 16, 2010, at 6:50 PM, Daryl Malas wrote:

> Adam and Dean,
>
> Perhaps you have misunderstood my comments.  My comment is, simply,  
> it is better to know and control the "ugly" truths rather than  
> simply sweep them under the rug and blindly believe they do not  
> exist.  In this way, you know what evil you will need to face,  
> rather than being surprised by the unknown proprietary solutions  
> vendors have created based on monetary rather than technology gains.

You are right. It is indeed better to know about the ugly than to  
ignore it. I have perhaps forecast its development all to clearly and  
proven unable to do anything about it, which tends to make one  
crotchety at best.

And I'd rather have a real routing protocol to handle the "LRF evil"  
within an administrative domain than hack the DNS to convey the same  
information. It is, I think, the lesser of two evils.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 17 Mar 2010 00:37:19 -0500

On Mar 16, 2010, at 11:19 PM, Henry Sinnreich wrote:

> This really sums up the enigma why the IETF should do work that  
> contradicts every principle of the Internet architecture and its  
> engineering.
>
> It may be useful to remember the  _solid_   track record of the   
> "stagnant world"

Not to mention that I still can't reliably make a SIP call. Bernie and  
I had to hack on things together for thirty minutes before we could  
make a call work to talk about E2MD earlier this week. But at least we  
didn't break down and use Skype... until today, when we needed to talk  
in a hurry.

--
Dean

---

From: Greger Viken Teigre <[email-masked]>
Date: Wed, 17 Mar 2010 20:57:56 +0100

On 15.03.2010 17:24, Adam Roach wrote:
>> Selecting a *UAS* that has the capabilities the caller envisions 
>> using (such as video) were certainly among the things that were among 
>> the intended use cases.
>>
>> I'm dubious about their suitability for selecting a route to reach 
>> the UAS, assuming its the same UAS you are seeking.
>
> That's the other 20%. :)

Yes, the toolset is there. Making it work in a multi-vendor, 
multi-party, multi-capability UA environment is far away.

>> capabilities that will be used on a call. It is an entirely 
>> reasonable use case for a UAC to invite with no offer, and then 
>> negotiate the use of voice and video because the UAS offers that. Its 
>> also entirely reasonable for a call to start out as audio only, for 
>> the caller and callee to learn as a result of discussion that both 
>> are video capable, and then add video to the call.
>>

I'm not sure I'm following this, but a video phone will for example be 
able to make PSTN calls over one peering relationship, high-def 
voice/AAC-LD over another, and video over a third. If the original call 
was to a URI with hunt functionality forking across all three, it's 
pretty random where the call will end up and any attempt with no offer 
or renegotiate to video afterwards is not likely to work very well from 
a user perspective.
g-)

---

From: Greger Viken Teigre <[email-masked]>
Date: Wed, 17 Mar 2010 21:32:36 +0100

I agree with Jon here (even though I feel partially responsible for 
starting a war of the worlds thread...)
SPEERMINT seems to be the right place. I have trying to get through all 
the current drafts there, and I see that some of the issues I raised 
here as a response to egress-route is really something that should be 
raised in SPEERMINT context.
g-)

On 17.03.2010 00:29, Peterson, Jon wrote:
>
> I'm not sure that dispatching malas-dispatch-sip-egress-route requires 
> us to untwist this particular Gordian knot, nor to resurrect TRIP, 
>  nor to declare some kind of interplanetary Armageddon.
>
> I think Otmar Lendl has been right on the mark in this discussion. He 
> points out that global directories like ENUM serve well as an LUF and 
> poorly as an LRF, to speak in the SPEERMINT idiom - I don't think this 
> is an especially controversial point. I read malas-dispatch-sip-egress 
> as a document that argues that knowing the results of the LUF doesn't 
> necessarily help you to find a next hop to route your call through. 
> Again, I'd say not especially controversial.
>
> malas-dispatch-sip-egress-route then goes on to specify a few NAPTR 
> syntaxes that could contain a sort of joint LUF/LRF routing 
> information. The only conceptual problem I have with this approach is 
> that the entity that typically provisions the LUF doesn't know the 
> local topology of the originating network well enough to say useful 
> things about the LRF -- that is indeed the entire motivation for 
> considering the LUF and LRF as separate lookups. The draft sort of 
> glosses this over with a lot of passive voice when describing how the 
> ENUM provisioning gets done. Is it done by the terminating side, or 
> the originating side, or somehow both?
>
> In any event, from a DISPATCH perspective, I'd propose the problem 
> seems to lie comfortable within the parameters of SPEERMINT. Surely 
> one of the SPEERMINT chairs must think this is a worthwhile effort...
>
> Jon Peterson
> NeuStar, Inc.
>

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 17 Mar 2010 17:01:29 -0400

+1 Daryl is right here. 

Can we let people try and solve their problems? At least in the intermediate
term vs seeing chaos rule? I'm getting this same thread in the E2MD
discussions.  I though the IETF was about trying to make the internet work
better.

The meta issue here is there are ..yes classic telecommunications carriers
have substantive technical problems interoperating or transitioning from
classic analog POTS to SIP centric solutions. GEE "what am I going to do
with my DMS 250 and 500's .. hummmm what do I do when I get a EOL letter for
my hundreds of 5ESS switches."

Part of the solution MAY assume a transitional mechanism that generally
accepts that some form of the classic intercarrier interconnection model may
exist and that policy MAY exist at each intermediate hop.

This assumes that you may need to crawl before you walk and that nirvana may
be a while off in the future.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Daryl Malas
Sent: Tuesday, March 16, 2010 6:00 PM
To: 'Dean Willis'; Adam Roach
Cc: [email-masked]
Subject: Re: [dispatch] I-D Action: draft-malas-dispatch-sip-egress-route-00

I believe we MUST solve this problem twice.  Let's be realistic.
Understanding the problem fully, defining the requirements, establishing the
group and hammering through the varying solutions will take 5 - 10 years to
complete.  The telecommunications industry will develop their own
proprietary mechanisms for doing this, creating greater fragmentation and
interoperability issues; or the IETF can step up and as an interim solution
say, since, you are going to solve this, do it this way.  At least in this
case, we will know where the industry is at in their resolution rather than
guessing at the plethora of "potentials" down the road.

Regards,

Daryl

-----Original Message-----
Of Dean Willis

> -- we need to make sure they don't destroy the vibrant world with 

Beautifully said! I read it just after my similar but less-elegant rant,
which presumes that the stagnant world is likely to be selected over the
vibrant through the simple processes of expediency, apathy, corruption,
greed, and fear. But then, I'm an optimist.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Wed, 17 Mar 2010 16:04:54 -0500

Let me make sure I understand this correctly. I'm pushing for adoption 
and publication of Daryl's draft, and you're trying to disagree with me 
by pushing for adoption and publication of Daryl's draft. Is that where 
we stand?

/a

---

From: Daryl Malas <[email-masked]>
Date: Thu, 18 Mar 2010 08:58:48 -0600

Are there any other thoughts on "Speermint-izing" this work?  --Daryl

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greger Viken Teigre
Sent: Wednesday, March 17, 2010 2:33 PM
To: [email-masked]
Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00)

I agree with Jon here (even though I feel partially responsible for starting a war of the worlds thread...)
SPEERMINT seems to be the right place. I have trying to get through all the current drafts there, and I see that some of the issues I raised here as a response to egress-route is really something that should be raised in SPEERMINT context.
g-)

Jon Peterson
NeuStar, Inc.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Mar 2010 15:06:47 -0400

> multi-party, multi-capability UA environment is far away.

I can't follow what this means after a couple of replies.
The Accept-Contact for callerprefs is specific to selecting among 
registered contacts that have hopefully been tagged with callee 
capabilities.

For use by an intermediary, at best it might be able to associate callee 
capabilities to alternative paths (presumably via configuration) and 
then apply the Accept-Contact rules to those to help choose the path.

For instance, I guess a proxy that is choosing between a TDM gateway and 
a "sip trunk" might give the TDM gateway a minimal set of capabilities, 
including voice, and then perhaps give the sip trunk none, which would 
cause it to do presumed matching.

But is anybody going to implement callerprefs in routing proxies?

> or renegotiate to video afterwards is not likely to work very well from 

And the solution is ...?

IMO its really bad to infer only basic voice except in cases where SDP 
is present in the invite and specifies non-basic media.

*Maybe* callerprefs could help, using the approach I mention above.

My simplistic answer is that if the R-URI is sip:... then the gateway 
ought to be last resort. If the R-URI is tel:... then it means I only 
expect telephone functionality via any sort of protocol that supports 
that, so you should feel free to use the GW as your first choice, if you 
wish.

	Thanks,
	Paul

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 19 Mar 2010 21:29:40 +0100

> Are there any other thoughts on "Speermint-izing" this work?  --Daryl

It's IMHO the right place to go.

btw, you might also want to take a look at
http://tools.ietf.org/id/draft-lendl-enum-sip-lr-00.txt
and the ideas (routing vs. retargetting) referenced there.

I haven't followed up on what happened to rosenberg-sip-ua-loose-route in
the end, but looking at your problem from that PoV might be instructive.

May next week's meeting be a productive one.

/ol

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 24 Mar 2010 03:43:27 -0400

> Behalf Of Adam Roach
> Sent: Monday, March 15, 2010 1:33 PM
> 
> path, even when that's not the optimal thing to do. 

Optimal for whom, and in what way?  

> The chances of such

You seem to have some very odd (and typical IETF bull) preconceptions about what SBC's can do or are capable of doing.  SBC's in general support video, HD voice, or any of the other neat things Gregor mentions.  Policies provisioned on the SBC's may limit what media one can do, or in some cases if transcoding has to happen then obviously you're limited to whatever codecs the transcoders can handle (as any media gateway would be), but that's really tangential.

> disallowed by protocol specification.

As a B2BUA, what SBC's do is in no way disallowed by the protocols in the IETF. (although certainly I don't really care if they are ;)

> elements living in the stagnant world.

If you live in this "vibrant world" the rest of us don't, what problems are there that need solving??  Usually one needs users and a population >1 to have problems.  The future always looks rosy compared to the present.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 24 Mar 2010 04:12:30 -0400

Not to argue your general tone, but you do realize that most of those things you list were actually generally profitable and successful in their time, right?  Sure their time may be past, but that doesn't mean they were failures.  I mean I used to be in the IP routing world before coming to voip, and SONET was the predominant long-haul transport which actually connected and formed the "Internet" in the 90's and early 2000's.  I dunno what it is mostly today, but I bet there's still tons of it out there.

And it's not like there weren't plenty of ultimate-failure companies building Ethernet switches or IP routers as well.  Or even HTTP browsers.

-hadriel
p.s. and sadly H.323 ain't dead yet either - for some reason it seems to be alive and kicking in certain regions of the World, and in certain niche market segments.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry Sinnreich
Sent: Wednesday, March 17, 2010 12:19 AM
To: Dean Willis; Adam Roach
Cc: [email-masked]; Daryl Malas
Subject: Re: [dispatch] War of the Worlds (was Re: I-D Action: draft-malas-dispatch-sip-egress-route-00)

This really sums up the enigma why the IETF should do work that contradicts every principle of the Internet architecture and its engineering.

It may be useful to remember the  _solid_   track record of the  "stagnant world"

 *   OSI
 *   X4.00 mail
 *   IN
 *   AIN
 *   ISDN
 *   SONET/SDH
 *   ATM
 *   BISDN
 *   H.323
 *   current re-incarnations such as PSTN/SIP and other (avoiding flames here)...
How many companies have disappeared building this stuff? Layoffs. Capital destruction.

The other enigma is the tolerance to associate the IETF with the reincarnations of these failures.

>I have long speculated that perhaps the best thing we can do is punt the "stagnant world" stuff to a different forum.
>I seem to recall many times suggesting that SIP should just be moved to the ITU so we can get on with building the Internet.

Well said.

Thanks, Henry

I have long speculated that perhaps the best thing we can do is punt the "stagnant world" stuff to a different forum. I seem to recall many times suggesting that SIP should just be moved to the ITU so we can get on with building the Internet. I'd happily add ENUM to the same bucket.

The problem is that we might wake up one day and realize that the Internet has been turned off, and all we have left is a stagnant backwater of telecommunications boundaries established by fat-and-happy politicos eager to preserve their own domains.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Mar 2010 10:39:52 -0400

Hadriel,

SBCs may be *capable* of preserving everything, but AFAIK in large part 
they exist as policy enforcement points to restrict one thing or another.

If there is only one such boundary between the caller and the callee, 
then the chances of everything working that the two ends want may be 
pretty good, and if something doesn't work there is a reasonable chance 
that policy changes can be made so that it will work.

But each additional hop between the caller and callee increases the 
possibility for some loss in functionality. By the time you have the 
caller, the caller's SP, the callee's SP, the callee, and maybe one or 
more transit providers, the likelihood of much beyond basic voice 
working starts getting very questionable. Of course its still 
*possible*, but what is the likelihood?

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 24 Mar 2010 13:06:09 -0400

Sure, then what he's saying is "because of policies people want to employ and enforce, I can't do things that don't comply with those policies".  Sure I believe that... it's a tautology.

With respect to media policies though, as far as I can tell, restricting the type of media, or even codecs within a given media type, is not _that_ popular - not for endpoint-to-endpoint sessions.  I bet maybe as much as 50% of the time, the codec/media-type munging by SBC's is done for fixing interop, not restriction policies.  They're frequently removed because the equipment _inside_ the carrier's core network (i.e., gateways and media servers) can't handle anything else and don't act well when given SDP they don't expect.

But if the signaling ends up going back out of the core, like to another UA or another domain, some SBC's can "undo" the changes they made (assuming operator policies don't restrict that too).

Although admittedly I may be wrong on how frequently it's done for interop, vs. billing/policies, vs. bandwidth issues.

-hadriel

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, March 24, 2010 10:40 AM
> To: Hadriel Kaplan

---

From: Adam Uzelac <[email-masked]>
Date: Wed, 24 Mar 2010 10:14:13 -0700

I can confirm the notion that Hadriel states below.  The "munging" that's
going on is more about facilitating the session than about restricting a
particular type of session.  With that said, there are indeed times that we
(as a SSP) would want to restrict, but those use cases are much fewer than
sorting out Interop issues.

Adam Uzelac
Global Crossing

On Wed, Mar 24, 2010 at 10:06 AM, Hadriel Kaplan <[email-masked]>wrote:

>
> Sure, then what he's saying is "because of policies people want to employ
> and enforce, I can't do things that don't comply with those policies".  Sure
> I believe that... it's a tautology.
>
> With respect to media policies though, as far as I can tell, restricting
> the type of media, or even codecs within a given media type, is not _that_
> popular - not for endpoint-to-endpoint sessions.  I bet maybe as much as 50%
> of the time, the codec/media-type munging by SBC's is done for fixing
> interop, not restriction policies.  They're frequently removed because the
> equipment _inside_ the carrier's core network (i.e., gateways and media
> servers) can't handle anything else and don't act well when given SDP they
> don't expect.
>
> But if the signaling ends up going back out of the core, like to another UA
> or another domain, some SBC's can "undo" the changes they made (assuming
> operator policies don't restrict that too).
>
> Although admittedly I may be wrong on how frequently it's done for interop,
> vs. billing/policies, vs. bandwidth issues.
>
> -hadriel
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 Mar 2010 10:32:44 -0700

Ooh! A gauntlet! It's been a while since we had one of these. I guess we 
all need a bit of catharsis.

> Optimal for whom, and in what way?

I guess I should have qualified that. I meant technically optimal -- 
that is, optimizing for the lowest end-to-end latency, jitter, and 
overall network resource utilization. IP routing does a reasonable job 
of getting this right -- artificially pinning the media to various 
points around the network defeats that.

> You seem to have some very odd (and typical IETF bull) preconceptions about what SBC's can do or are capable of doing.

Defensive much? I didn't say that the SBCs were incapable of passing 
this kind of media along. I was attempting to point out that the 
operators who deploy these kinds of architectures are not typically of 
the mindset that lends itself to forward thinking. After all, they're 
sinking untold costs into a network that does quite precisely what their 
old network did. If that qualifies as "progress," then something as 
radical as hi-def audio on the same scale would probably qualify as 
"Ragnarök."

That said, if SBCs actually *are* B2BUAs as you claim below (which they 
aren't, but let's buy that conceit for a second), then they must 
implement all higher-level services that the endpoints they sit between 
expect to invoke. Because, if they really are B2BUAs, then they're the 
"other user agent" in two different (but related) calls, and they need 
to understand everything that the actual endpoints say. That means that 
handsets will always be stuck waiting on SBCs to catch up when they try 
to deploy new services.

> As a B2BUA, what SBC's do is in no way disallowed by the protocols in the IETF. (although certainly I don't really care if they are ;)

Again, even if they were true B2BUAs, they run afoul of some rather 
well-established Internet principles. I know that things like the 
end-to-end principle seem like quaint platitudes to you, and I'm not the 
person to convince you otherwise.

But that's not the practical issue. You're smart enough to know that 
SBCs are in no way compliant B2BUAs. They don't satisfy the requirements 
of user agents, nor do they hold themselves to the restrictions of being 
a proxy. They pick-and-choose between these behaviors, sometimes within 
a single message. That's out of spec, and it causes real and 
quantifiable problems.

For example: if SBCs were actual, real, full-fledged back-to-back user 
agents, we wouldn't be stuck with defining alternative connection models 
to accommodate their peculiarities. As compliant user agents, they would 
have no issues with the MSRP protocol as defined.

> If you live in this "vibrant world" the rest of us don't, what problems are there that need solving??  Usually one needs users and a population>1 to have problems.  The future always looks rosy compared to the present.
>    

Although I'm sometimes guilty of reading through large backlogs of email 
and replying to messages as I come across them, I have generally taken 
it upon myself to at least read to the end of a thread before I reply in 
that thread. This lets me avoid asking questions that have already been 
answered or making assertions that have already been refuted.

http://www.ietf.org/mail-archive/web/dispatch/current/msg01549.html

(You can skip directly to the final paragraph)

/a

---

From: Dean Willis <[email-masked]>
Date: Wed, 24 Mar 2010 13:07:42 -0500

Hadriel Kaplan wrote:
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Adam Roach Sent:
>> Monday, March 15, 2010 1:33 PM
>> 
>> relationships of the PSTN in a SIP network. And the path that has
>> been taken, for better or worse, involves the heavy use of SBCs and
>> other devices that impose a rather strict control on the way things
>> are done. These devices largely ensure that the media path follows
>> the signaling path, even when that's not the optimal thing to do.
> 

Optimal in the "internet" sense: the shortest/least used available
route, as would be described by the IP routing topology from address A to B.

> 
>> The chances of such networks deploying video, hi-def voice, or any
>> of the other really neat things that Greger mentions are slim to
>> none. This, of course, is NOT Daryl's fault. But it's where the
>> egress-route work comes from.
> 
> You seem to have some very odd (and typical IETF bull) preconceptions
> about what SBC's can do or are capable of doing.  SBC's in general
> support video, HD voice, or any of the other neat things Gregor
> mentions.  Policies provisioned on the SBC's may limit what media one
> can do, or in some cases if transcoding has to happen then obviously
> you're limited to whatever codecs the transcoders can handle (as any
> media gateway would be), but that's really tangential.

I believe Adam is referring to the fact that it's the old-school telecom
people who are building this sort of topology. They don't have a great
history of successful innovation. They occasionally try to offer a new
service, but only after it's been much more successfully deployed in an
"Internet" fashion by the new-school people. Does Youtube require SBCs?
How about iTunes? AOL's Instant messenger? Facebook?

> 
> 
>> Greger is speaking more towards the network you seem to have in
>> mind -- one in which end-to-end SIP calls are possible, without
>> SBCs or similar control boxes clobbering new services and mangling
>> the ability to convey novel media from one endpoint to another.
>> Networks where we don't need to define alternate connection models
>> for protocols simply to accommodate network elements that do things
>> that are explicitly disallowed by protocol specification.
> 
> As a B2BUA, what SBC's do is in no way disallowed by the protocols in
> the IETF. (although certainly I don't really care if they are ;)

Right. What they do is controlled by the policies and mindsets of those
who purchase and install them. They live in a different world, where
innovation is slow and painful. It's also a world where long-term
reliability and stability are heavily rewarded.

>>  about the form of URLs that one might want to put in ENUM. It
>> satisfies the requirements of the stagnant world, and doesn't even
>> have any normative impacts on any protocol anywhere. It's harmless,
>> and lets the people in the vibrant world concentrate on solving the
>> problem in a more general way without having to accommodate the
>> peculiarities of network elements living in the stagnant world.
> 
> If you live in this "vibrant world" the rest of us don't, what
> problems are there that need solving??  Usually one needs users and a
> population >1 to have problems.  The future always looks rosy
> compared to the present.

Why are the kids migrating towards Facebook/Youtube etc. as their
communications channels?

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 24 Mar 2010 16:56:16 -0400

> Sent: Wednesday, March 24, 2010 1:33 PM
>

Oh, I didn't realize typical IP routing took into account latency, jitter, packet-loss and overall network utilization.  Oh wait, that's because it *doesn't*.  MPLS-TE does more so, and its extensions for ospf/isis-te - but there's this funny thing that happens with that - ALL the traffic flows that way (well, all the traffic for that FEC/prefix).  So if you only want *some* traffic to flow that (better) way, like oh for example money-generating voip traffic, you gotta make it a different FEC (which SBC's do), or apply router-level per-flow/per-call gates/policies.  Obviously going across the public Internet there's nothing much better you can do than best-effort routing, but for owners/operators of the network infrastructures, they have other options. YMMV.

> about what SBC's can do or are capable of doing.
> 

Actually, most operators *want* new capabilities, new services, new media types, etc.  They're stuck in many cases because of legacy deployed gear, no doubt, but they really do want to provide better and newer stuff.

> handsets will always be stuck waiting on SBCs to catch up when they try

Ironically, SBC's seem to be the ones usually waiting on endpoints to implement new things. (seriously)

> handsets will always be stuck waiting on SBCs to catch up when they try

Of course you're right, in some particulars SBC's are not a "full" B2BUA, but instead walk a fine line trying to be less than a "full" B2BUA, specifically to try and avoid getting in the way of new mechanisms/media/protocols.  But I have not seen any RFC that specifies what a B2BUA must or must not do - yes, it's the combination of a UAC and UAS for two distinct sessions, but I don't know of any doc that says what I can and cannot copy back/forth among those two sessions.  And that is not specific to SBC's either - lots of app-servers/softswitches/pbx's are "mostly" but not entirely B2BUA's in signaling, and partial or not B2BUA's in media.

> have no issues with the MSRP protocol as defined.

You're not stuck with it.  We don't *need* the alternative connection model or msrp changes to function.  We *want* it, for an optimization - in the ipv4/v6 case to let media go "direct" when it can, or not be converted back/forth v6/v4/v6; in the MSRP case so it can actually scale and be cost-effective.  They're more pragmatic/practical issues than technical.

> (You can skip directly to the final paragraph)

I read it, and it refutes nothing.  I didn't literally mean a population of "1".  I meant a significant population, with numerous vendors, etc. (and I think you knew that ;) 

-hadriel
p.s. Is it sad that when I read "gauntlet" I first thought of a great classic arcade game? :)

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 24 Mar 2010 17:03:12 -0400

> Sent: Wednesday, March 24, 2010 2:08 PM
> To: Hadriel Kaplan
> 

Unless something drastic has changed in the past 6 years, the public Internet routing model does not provide a shortest in the English sense of the word.  It is not based on physical distance or latency.  Nor is it based on least-used.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 24 Mar 2010 17:20:59 -0400

> How about iTunes? AOL's Instant messenger? Facebook?

The application, protocol, delivery, usage, and expectation model for those applications is very different from VoIP.  And you know that. AOL-IM is closer, but it's a closed walled-garden... how evil!

> Why are the kids migrating towards Facebook/Youtube etc. as their

What does that that have to do with anything?  They're not replacements/instead-of - they're something different altogether.  Why do more kids play Xbox Live and talk over the game headsets?  It must be because it's not provided by a telco!?

Why do more and more kids use SMS, or mobile phones?  Those are provided by telco's.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Mar 2010 17:41:20 -0400

> Oh, I didn't realize typical IP routing took into account latency, jitter, packet-loss and overall network utilization.  Oh wait, that's because it *doesn't*.  MPLS-TE does more so, and its extensi…

RSVP?

> Actually, most operators *want* new capabilities, new services, new media types, etc.  They're stuck in many cases because of legacy deployed gear, no doubt, but they really do want to provide bett…

They want the new capabilities that they can monetize.
But if its some new capability that can be realized by cooperation by 
the two ends, with just a "dumb pipe" connection, then there is no 
motivation to remove inhibitions.

And don't get me wrong - I think its a fine thing for SPs to monetize 
added value services that really add value that the callers want enough 
to pay for.

	Thanks,
	Paul